{"slug": "ai-wont-fix-a-broken-business-process", "title": "AI Won’t Fix a Broken Business Process", "summary": "An enterprise AI practitioner argues that companies launching AI projects should begin with workflow design rather than model selection, warning that deploying models into poorly defined processes can scale existing confusion across thousands of records. The piece outlines a five-part process framework — input, decision, action, validation, and outcome — and contends that questions of data ownership, business rules, and permissions matter more than prompt tuning.", "body_md": "*Why enterprise AI projects should start with workflow design, not model selection*\n\nAn enterprise AI project often starts with the same question:\n\n**Which model should we use?**\n\nShould it be GPT, Claude, Gemini, an open-source model, or a smaller model running privately?\n\nThat question matters, but it is rarely the best starting point.\n\nA more useful question is:\n\n**Which business process are we trying to improve?**\n\nMany enterprise processes are already difficult before AI enters the picture. Data is incomplete. Responsibilities are unclear. Different systems contain conflicting information. Business rules exist only in people’s memories. Exceptions are handled manually. Nobody can clearly explain where a process begins, where it ends, or how success is measured.\n\nAdding AI to such a process does not automatically solve these problems.\n\nIt may simply make the process faster, larger, and more difficult to understand.\n\n**1. The AI Project Usually Starts in the Wrong Place**\n\nImagine a company building an AI assistant for its sales team.\n\nThe assistant should recommend the next action for each customer. It might suggest a follow-up call, identify an inactive opportunity, or remind a salesperson about an unanswered request.\n\nAt first, this sounds like a straightforward AI feature.\n\nBut several questions appear immediately:\n\nWhat does “next action” actually mean? Who is responsible for defining it? Which data should the assistant trust? What happens when the CRM contains duplicate customer records? How should it treat an opportunity with no recent activity? What if the customer has already contacted support about the same issue? How do we measure whether the recommendation was useful?\n\nThese are not primarily model-selection questions.\n\nThey are questions about process definition, data ownership, business rules, permissions, and workflow design.\n\nA team can spend weeks improving prompts while the real problem remains unresolved. The model may become better at producing recommendations, but the recommendations are still based on unclear inputs and an ambiguous process.\n\nThe result is a polished solution to the wrong problem.\n\n**2. AI Can Scale a Broken Process**\n\nConsider a typical customer follow-up process.\n\nA salesperson records a meeting in the CRM. The system creates a follow-up task. A manager reviews the opportunity. Another system contains the customer’s payment status. The salesperson is expected to decide what should happen next.\n\nNow imagine adding AI.\n\nThe model summarizes the meeting, extracts action items, recommends a follow-up date, and assigns a task automatically.\n\nThat may be useful. But it does not resolve the underlying process problems.\n\nIf customer ownership is unclear, the AI may assign the task to the wrong person.\n\nIf the CRM contains duplicate records, the AI may attach the activity to the wrong customer.\n\nIf the business has no clear definition of an inactive opportunity, the model may produce inconsistent recommendations.\n\nIf the payment system and CRM disagree, the AI may confidently interpret the wrong status.\n\nThe system now operates more quickly, but the underlying confusion remains.\n\nThis is more than a traditional “garbage in, garbage out” problem.\n\nA human working with poor information may make one mistake. An automated AI workflow can repeat the same mistake across thousands of records.\n\n**A human can create isolated confusion. AI can scale it.**\n\nThat is why the phrase “chaos in, speed and scale out” describes a real enterprise risk. AI does not need to be inaccurate in every case to cause damage. It only needs to operate inside a poorly defined process without sufficient controls.\n\n**3. Before Choosing a Model, Understand the Workflow**\n\nA useful way to examine any business process is to break it into five parts:\n\nInput\n\n  ↓\n\nDecision\n\n  ↓\n\nAction\n\n  ↓\n\nValidation\n\n  ↓\n\nOutcome\n\nEach part deserves separate attention.\n\n**Input**: What information enters the process? Where does it come from? Is it complete, current, and correctly associated with the right customer, order, employee, or transaction?\n\n**Decision**: What decision must be made? Is it based on explicit business rules, interpretation, or judgment? Can the decision be expressed deterministically?\n\n**Action**: What happens after the decision? Is a task created, a message sent, a record updated, or a financial transaction initiated?\n\n**Validation**: What must be checked before the action is accepted? Are permissions, limits, approvals, and business constraints enforced?\n\n**Outcome**: How do we know the process worked? Did the customer receive the correct response? Was the task completed? Did the action reduce manual work or improve response time?\n\nThis decomposition helps identify where AI belongs.\n\nAI may be useful for interpreting an unstructured meeting note, extracting information from an email, classifying a customer request, or suggesting a next action.\n\nIt should not automatically replace deterministic validation, authorization, transaction handling, or business rules.\n\nThe model can help interpret ambiguity. The application must still control what is allowed to happen.\n\n**4. Data Ownership Is Part of the AI Architecture**\n\nData quality is often treated as a preparation step before the AI project begins. In reality, it is part of the architecture itself.\n\nA workflow may depend on a CRM, ERP, ticketing system, internal documents, and communication tools. The important question is not simply whether the data exists.\n\nThe important questions are: Which system is authoritative? Who owns each field? How fresh must the data be? How are customers, users, and transactions identified across systems? Which information can the AI access, and under whose permissions?\n\nThese are architectural questions because they directly affect what the AI is allowed to interpret and what the application is allowed to do.\n\nA model may generate a convincing recommendation from incomplete or conflicting information. That does not make the recommendation reliable. If two systems disagree about a customer’s status, the AI cannot resolve that conflict merely by producing a more fluent answer. The workflow needs an explicit rule for resolving it.\n\nData ownership, therefore, is not administrative housekeeping. It is part of the control system that makes AI useful inside an enterprise.\n\n**5. Use AI Where It Creates Leverage**\n\nNot every step in a business process needs AI.\n\nSome tasks are already deterministic:\n\nChecking whether a required field is empty\n\nCalculating a discount\n\nVerifying a user’s permission\n\nMatching an exact customer identifier\n\nApplying a contractual limit\n\nUpdating a transaction inside a database\n\nUsing an LLM for these tasks may introduce unnecessary cost, latency, and uncertainty.\n\nOther tasks involve ambiguity:\n\nUnderstanding the meaning of an email\n\nExtracting information from a document\n\nSummarizing a conversation\n\nClassifying a customer request\n\nDetecting the likely intent behind a message\n\nSuggesting a response or next action\n\nThese are stronger candidates for AI because language models can handle variation and unstructured information more flexibly than traditional rules.\n\nA useful principle is:\n\n**Use AI for ambiguity. Use deterministic software for certainty.**\n\nThe goal is not to introduce the most sophisticated AI architecture into every feature. It is to use an approach that creates meaningful value while keeping failure understandable and controllable.\n\n**6. The Real Unit of AI Adoption Is the Workflow**\n\nAn AI feature can look successful in isolation and still fail in practice.\n\nA meeting-summary feature may generate excellent summaries. But what happens afterward?\n\nDoes the summary connect to the correct customer? Are action items extracted reliably? Are tasks assigned to the right people? Are deadlines represented correctly? Does the salesperson actually use the generated tasks? Can a manager see whether follow-ups were completed?\n\nThe value is not created by the summary alone.\n\nThe value is created when the summary becomes part of a functioning workflow.\n\nThis changes how AI projects should be measured.\n\nInstead of focusing only on model quality or response fluency, teams should examine operational outcomes:\n\nHow much manual work was removed?\n\nDid response times improve?\n\nDid routing errors decrease?\n\nWas less information re-entered across systems?\n\nDid users accept or ignore the recommendations?\n\nHow often did humans need to correct the result?\n\nDid the process create new review or rework costs?\n\nA model response is an intermediate artifact. The business outcome is the real product.\n\n**7. A Practical Way to Start**\n\nA more reliable enterprise AI project can begin with a small process-mapping exercise.\n\nFirst, document the process as it actually happens — not as it is supposed to happen according to a presentation or specification.\n\nIdentify the systems involved, the people responsible, the common exceptions, and the points where manual work or confusion appears.\n\nThen simplify the process before automating it. Remove unnecessary handoffs. Clarify ownership. Define the meaning of important fields. Decide which system is authoritative for each type of information.\n\nNext, separate interpretation from enforcement.\n\nAsk which parts require language understanding or judgment, and which parts should remain deterministic. Define the boundaries before selecting the model.\n\nOnly then choose a narrow AI opportunity and define its expected outcome. The first version might only prepare a recommendation for a human rather than execute an action automatically.\n\nFor a low-risk feature such as summarization, rewriting, or translation, a team may reasonably test a model quickly. The cost of failure is limited, and the prototype can help determine whether the feature is useful at all.\n\nBut once the feature becomes part of a business-critical workflow, process design can no longer be postponed. A successful demo is not evidence that the surrounding business system is ready for automation.\n\nThe level of control should reflect the cost of failure.\n\nLow-risk tasks may run with minimal intervention. Higher-impact actions should involve validation, approval, monitoring, or a reliable way to reverse the result.\n\n**8. The Model Is Not the Business Process**\n\nThe model is only one component in the system.\n\nThe surrounding application still owns the responsibilities that make the workflow dependable: identity, permissions, transactions, business rules, workflow state, retries, idempotency, auditability, error handling, and user experience.\n\nThe model may interpret a request, extract information, classify an issue, or suggest the next action. The application must still determine whether that suggestion is permitted, valid, and safe to execute.\n\nThis distinction becomes especially important when an AI feature moves from assisting a user to taking action on the user’s behalf.\n\nSending a draft email and sending a legally significant customer notification are not equivalent operations. Recommending a discount and applying that discount to an order are not equivalent operations either.\n\nThe more costly the failure, the stronger the control boundary should be.\n\nThat is why the right architecture is rarely “let the model run the process.” It is closer to this:\n\nThe model interprets\n\nThe application validates\n\nThe business rules decide\n\nThe workflow executes\n\nThe system records\n\nThis does not make the AI less useful. It gives the AI a place where its strengths can be used without allowing its uncertainty to control the entire business process.\n\n**Conclusion**\n\nAI does not remove the need for process design.\n\nIt makes process design harder to ignore.\n\nWhen a workflow is unclear, AI may hide the underlying problems behind fluent language and fast execution. When data ownership is weak, AI may spread incorrect interpretations across systems. When business rules are undefined, AI may produce recommendations that sound reasonable but cannot be safely enforced.\n\nThe better approach is to start with the workflow.\n\nUnderstand the inputs. Clarify the decisions. Define the actions. Establish validation. Measure the outcome. Then decide where AI can create real leverage.\n\nThe model matters, but it is not the business process.\n\n**AI won’t fix a broken business process. But it can make a well-designed process significantly more capable.**", "url": "https://wpnews.pro/news/ai-wont-fix-a-broken-business-process", "canonical_source": "https://dev.to/ikilic/ai-wont-fix-a-broken-business-process-3ma0", "published_at": "2026-09-12 21:41:33+00:00", "updated_at": "2026-09-12 22:25:11.055228+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-products", "ai-agents"], "entities": ["GPT", "Claude", "Gemini"], "alternates": {"html": "https://wpnews.pro/news/ai-wont-fix-a-broken-business-process", "markdown": "https://wpnews.pro/news/ai-wont-fix-a-broken-business-process.md", "text": "https://wpnews.pro/news/ai-wont-fix-a-broken-business-process.txt", "jsonld": "https://wpnews.pro/news/ai-wont-fix-a-broken-business-process.jsonld"}}