Veera Babu Tiragatla

Tech Insights · Veera Babu Tiragatla

The Machine Can Recommend. The Architecture Must Answer.

How leaders must redesign enterprise architecture for the era of algorithmic delegation

Veera Babu Tiragatla · 16 minute read

Enterprise AI architecture flow showing context and data foundation, AI recommendation, authority gate, decision and action, and learning feedback loop
Enterprise AI recommendations become serious when they pass through authority, action and learning loops. Architecture decides where those boundaries sit.

For most of the digital era, enterprise systems were expected to remember, calculate and report.

That was already difficult work. A transaction had to be captured correctly. A database relationship had to make sense. A batch process had to finish. A dashboard had to reconcile with the numbers someone trusted elsewhere.

But the role of enterprise systems is changing again.

They no longer only show what happened. Increasingly, they suggest what should happen next.

A machine can recommend a supplier. It can prioritise a customer. It can flag an employee record for review. It can summarise a financial exception, propose a planning adjustment, draft a decision rationale or allow an agent to take the next step through connected systems.

That shift is more serious than it first appears.

Across years of working with enterprise data, SAP landscapes, reporting platforms and modern analytics, I have seen a pattern repeat itself in different forms. The technical system may complete its job, but the harder question begins after that. The numbers arrive. The report opens. The exception is visible. Then people have to decide what the information means, who has the authority to act and what consequence the organisation is prepared to own.

AI does not remove that moment.

It moves it closer to the system.

When a system only reports, the person reading the report still carries the interpretation. When a system recommends, some of that interpretation has already been packaged into the output. The system is no longer only presenting evidence. It is presenting a preference.

And preference, inside an enterprise, is never neutral.

The machine can recommend.

The architecture must answer.

When information acquired authority

The history of enterprise technology can be read as a gradual movement toward consequence.

At first, systems recorded business activity. An order was placed. Inventory moved. A payment was received. A cost centre was updated. The main question was reliability: did the system preserve the event correctly?

Then systems reported. Data warehouses, business intelligence tools and dashboards made information visible across functions. The main question became consistency: could people see the same numbers and trust how they were produced?

Then systems predicted. Forecasting, scoring and machine-learning models helped organisations anticipate risk, demand, churn, fraud or delay. The main question became accuracy: did the model estimate the future well enough to be useful?

Now systems recommend. Generative AI, copilots, data agents and workflow agents can interpret context and propose actions in natural language. The main question is no longer only whether the answer is accurate. It is whether the answer has been given the right kind of authority.

That is a different architectural problem.

I think of this as The Authority Ladder.

The path looks simple, but each step carries more weight:

  1. Record: the system remembers.
  2. Report: the system displays.
  3. Predict: the system estimates.
  4. Recommend: the system prefers.
  5. Act: the system changes reality.
  6. Learn: the system influences future preference.

The higher the system moves on this ladder, the less architecture can be treated as invisible plumbing.

Architecture becomes the structure that decides what the machine is allowed to know, what it is allowed to infer, what it is allowed to suggest and how far that suggestion may travel before a human being must take responsibility.

This is partly a technology problem. But it is also an old organisational problem appearing in a new technical form.

Enterprises have always delegated authority. A board delegates to executives. Executives delegate to process owners. Process owners delegate to teams, roles, controls and systems. Good organisations do not treat delegation as a vague hope. They define the boundary of the authority being delegated, the conditions under which it may be used and the evidence required when that authority is exercised.

AI introduces a new participant into that chain of delegation.

The mistake is to treat the machine as if it is only a tool when, in practice, its recommendations can begin to shape attention, priority and action. It may not hold responsibility in the human sense, but it can still exercise influence. Architecture is where that influence must be bounded.

In economic language, this is a new version of an old problem: the principal-agent problem.

An organisation delegates work to people, teams, vendors and systems because no leader can decide everything directly. But delegation always creates an alignment risk. The agent may optimise for a narrower goal than the principal intended. It may act on incomplete information. It may pursue speed, efficiency or local success while creating a wider organisational cost.

AI makes this familiar problem more subtle.

The system may not have ambition, politics or self-interest in the human sense. But it can still optimise toward the objective it was given, the data it can see and the authority it was allowed to exercise. If those boundaries are poorly designed, the recommendation may be technically rational and organisationally wrong.

This is also why authority inside enterprises is changing shape. Traditional organisations rely heavily on written policy, defined roles, approvals and human chains of command. AI adds a new layer of algorithmic authority: recommendations, rankings, summaries and suggested actions produced by systems that people may begin to treat as legitimate simply because they appear inside trusted workflows.

That authority must not be allowed to emerge accidentally.

Every recommendation contains a hidden policy

A recommendation sounds like a technical output. In practice, it often contains a policy choice.

Consider a procurement example.

An AI-enabled system recommends Supplier A over Supplier B. On the surface, this may look like a straightforward result based on price, delivery history and risk indicators. But beneath that recommendation are choices the organisation may not have made consciously enough.

Did the system treat lowest cost as the main definition of “best”? Did it include sustainability risk? Did it weigh delivery speed more heavily than supplier concentration? Did it consider geopolitical exposure, ethical sourcing, contract flexibility, carbon impact or the organisation’s long-term dependency on that supplier?

If those priorities are not explicit, the recommendation may appear objective while quietly reflecting a hidden hierarchy of values.

The same pattern appears in other domains.

A customer service AI may recommend which customer should be escalated first. That decision may contain assumptions about revenue, loyalty, risk, fairness and reputational impact.

A finance AI may flag an exception as material or immaterial. That judgement may depend on thresholds, timing, account sensitivity, business-unit history and audit expectations.

An HR AI may summarise a workforce pattern. That summary may reflect choices about what counts as performance, potential, risk, engagement or attrition.

None of these choices are merely technical.

They decide what the organisation notices. They decide what receives attention. They decide which trade-offs become visible and which ones disappear behind a polished sentence.

This is why the phrase “AI recommendation” can be misleading. A recommendation is not simply the last step of a model. It is the visible tip of a larger authority structure.

Somewhere beneath it, the organisation has already decided what counts.

The problem is that many organisations have not decided it deliberately.

Fluency is not accountability

Generative AI creates a new kind of enterprise risk because its outputs often sound more settled than the situation really is.

A dashboard can look incomplete. A spreadsheet can look provisional. A human analyst may hesitate while explaining uncertainty. But a fluent AI response can arrive with a smoothness that feels like confidence.

That confidence can be useful when the underlying context is strong. It can be dangerous when the architecture beneath the answer is weak.

A polished explanation does not prove that the right data was used. It does not prove that the business definition was shared. It does not prove that the model understood the consequence of the recommendation. It does not prove that the user has the authority to act.

It only proves that the system can produce language that feels complete.

In a real enterprise, that distinction matters.

A planner may accept a recommendation because it is well explained. A manager may forward a summary because it sounds balanced. A business user may treat an AI-generated rationale as if the hard thinking has already been done.

But fluency cannot attend the audit committee. It cannot accept professional liability. It cannot face a supplier, employee, regulator, customer or board and explain why the organisation allowed a machine-generated preference to shape a human outcome.

People can delegate work.

They cannot delegate responsibility in the same way.

That is why architecture must make confidence inspectable. It must show not only what the system recommends, but what kind of authority the recommendation deserves.

Architecture now determines the limits of machine authority

The important architectural question is no longer only, “Can the system access the data?”

That question still matters, but it is too small for the AI era.

The better question is:

What is the machine allowed to do with the authority created by that data?

There are different levels of machine authority. They should not be blurred.

At the lowest level, the system may only retrieve information. It answers, “What do we know?”

At the next level, it may interpret. It answers, “What does this appear to mean?”

Then it may recommend. It answers, “What should be considered next?”

Then it may approve. It answers, “This action is permitted.”

Then it may execute. It changes something in the business environment.

Each level requires different controls.

Read access is not recommendation authority. Recommendation authority is not approval authority. Approval authority is not execution authority. Execution authority is not ownership of consequence.

These distinctions should be designed into the architecture, not negotiated informally after a mistake.

For example, an AI assistant that summarises overdue invoices may need access to customer, payment and dispute information. But that does not mean it should recommend credit actions without showing policy context. And even if it recommends an action, that does not mean it should block the customer account automatically.

The architecture must decide where the boundary sits.

That boundary may depend on value, risk, reversibility, customer impact, legal obligation, audit requirements and the maturity of the process.

Low-risk, reversible actions may allow more automation. High-impact or hard-to-reverse actions may require explicit human review. Sensitive employee, customer, financial or compliance decisions may require stronger contestability and traceability.

This is not bureaucracy. It is proportional authority.

The more consequence a machine can create, the more precisely its authority must be defined.

The cost of control is real

There is an obvious objection to this argument.

If every AI recommendation requires more explanation, more traceability and more approval logic, do we not destroy the speed that made AI attractive in the first place?

That objection deserves to be taken seriously.

Enterprise architecture can become heavy. Governance can become performative. Controls can multiply until people stop trusting the process and start finding ways around it. A system that forces every low-risk recommendation through the same ceremony as a high-impact decision will not become safer. It will become ignored.

The goal is not to slow everything down.

The goal is to create safe speed limits.

A warehouse replenishment suggestion below a small threshold does not need the same authority model as an AI-generated recommendation to block a customer account, change supplier allocation during a disruption or flag an employee for investigation. The architecture should recognise that difference.

Some decisions need speed because delay itself creates risk. Some decisions need friction because speed creates harm. Mature AI architecture does not choose between velocity and control in the abstract. It classifies the consequence, then designs the right amount of authority around it.

This is where the work becomes more subtle than slogans about “human-in-the-loop.”

The question is not always, “Should a human approve this?”

Sometimes the better questions are:

Good controls should protect judgement without suffocating useful work.

A practical decision rule: reversibility and consequence

The most useful question is not whether AI should have autonomy.

The useful question is where autonomy is justified.

A simple way to decide is to compare two dimensions:

This creates a practical rule for enterprise AI architecture:

Decision type Example Architectural posture
Low consequence, highly reversible Reordering a low-value consumable under an approved threshold High speed, high automation
Low consequence, less reversible Publishing a routine customer message or updating a non-critical workflow rule Fast execution with lightweight review or rollback
High consequence, reversible Temporarily reallocating inventory during disruption or changing a customer service priority Proportional friction, visible rationale and logged human oversight
High consequence, hard to reverse Revoking a credit line, changing supplier allocation for a critical component, flagging an employee for formal review Strong human authority, contestability, escalation and full traceability

This matrix is intentionally simple. It will not answer every case. But it helps move the discussion away from two weak extremes: either “let the AI do everything” or “force a human approval on everything.”

The architectural discipline is to match autonomy to consequence.

When the action is low-risk and reversible, speed may be the responsible choice. When the action can affect money, rights, reputation, safety, compliance or long-term resilience, friction is not a failure of design. It is part of responsible design.

Data lineage is no longer enough

Traditional data lineage asks an important question:

Where did this value come from?

That question remains essential. If an output cannot be traced back to reliable sources, it should not be trusted in serious work.

But AI-era lineage has to go further.

When a system generates a recommendation, the enterprise needs to understand not only where the data came from, but how the recommendation acquired its shape.

The new questions are harder:

This is no longer only data lineage.

It is authority lineage.

A number may move through a pipeline. A recommendation moves through a chain of evidence, meaning, permission, model behaviour, user trust and organisational action.

If that chain is invisible, the organisation may still have technical traceability while lacking decision traceability.

That is a serious gap.

It means the organisation may know which table supplied a value, but not why that value became the basis for a recommendation. It may know which system executed an action, but not why the action was considered legitimate. It may know who clicked approve, but not whether the person understood the assumptions beneath the suggestion.

In traditional reporting, this was already a problem.

In AI-enabled decision environments, it becomes a structural risk.

The AI Authority Ledger

A useful way to think about this is to create an AI Authority Ledger around important recommendations.

Not a literal ledger in every case, but an architectural discipline: a way to ensure that every significant machine recommendation can answer six questions.

1. Evidence: what was allowed to matter?

The system should make clear which data sources, documents, signals and historical patterns shaped the recommendation.

This matters because omitted evidence can be as important as included evidence.

A supplier recommendation that includes price and delivery but excludes concentration risk is not simply incomplete. It is biased toward a particular idea of value.

2. Meaning: whose definition was used?

Enterprise terms often carry local meanings. “Active customer,” “priority supplier,” “high risk,” “material exception,” “late delivery” and “available stock” may not mean the same thing across functions.

AI does not remove that problem. It can hide it behind natural language.

The architecture should connect recommendations to governed definitions, semantic models, business rules and ownership.

3. Objective: what version of “best” was optimised?

Every recommendation implies an objective.

Best for cost? Best for speed? Best for compliance? Best for customer trust? Best for short-term margin? Best for long-term resilience?

If the objective is not visible, the recommendation may be technically reasonable and strategically wrong.

4. Authority: what was the AI allowed to do?

The architecture should distinguish between informing, interpreting, recommending, approving and executing.

This distinction should be explicit in permissions, workflow design, user interface language and audit trails.

An AI output should not quietly move from “suggestion” to “decision” because the screen made it convenient.

5. Contestability: could a person challenge it?

A recommendation that cannot be challenged becomes a soft command.

Human oversight is weak if the human can only accept the output or work around the system. Meaningful oversight requires enough evidence, context and time to question the recommendation.

The user should be able to ask:

6. Consequence: who owns what happens next?

The final question is the most human one.

If the recommendation is followed and causes harm, confusion, unfairness, financial loss or operational failure, who explains it?

Not in theory. In the actual organisation.

The architecture should make that ownership visible before the recommendation is acted upon.

Otherwise, accountability appears only after damage has already occurred.

A real enterprise scenario: supplier selection during disruption

Imagine a procurement team using an AI assistant inside an enterprise platform during a shipping disruption.

The business asks:

“Which supplier should we choose for this urgent component?”

The AI recommends Supplier A.

The answer looks sensible. Supplier A has the best recent delivery record, a competitive price and available capacity. The AI produces a short rationale that reads well. It may even be right for the immediate shortage.

But a careful architecture would not stop at the recommendation.

It would ask:

Without those questions, the system may optimise locally while creating a wider organisational weakness.

The recommendation may be good for the immediate purchase and poor for resilience. It may solve this week’s shortage by deepening next quarter’s dependency.

That is the kind of risk AI can make harder to see. Not because the technology is useless, but because it can make a partial view feel complete.

A second scenario: customer prioritisation

Now consider customer service.

An AI system recommends which cases should be handled first. It uses sentiment, customer value, contract level, open issues and predicted churn risk.

Again, the output may be useful.

But the architecture must answer deeper questions.

Does the system always prioritise high-revenue customers over smaller customers with urgent needs? Does it treat anger as a stronger signal than quiet dissatisfaction? Does it reinforce historical service inequality because some customers have more documented interactions than others? Does it recognise customers who lack the language, confidence or time to describe their problem dramatically? Does the agent have authority only to prioritise, or can it trigger compensation, escalation or contractual commitments?

These are not only model questions.

They are architecture questions because architecture decides where data, rules, permissions, workflow and human judgement meet.

If the organisation cannot answer them, then the AI is not merely recommending work. It is quietly reshaping service values.

A third scenario: employee risk flags

The most sensitive examples involve people.

Suppose an AI system summarises workforce information and flags an employee group for retention risk, performance concern or compliance review.

Here, the architecture must be especially careful.

What data was permitted? Who can see the output? Which attributes are excluded? Could the recommendation unfairly affect opportunity, reputation or trust? Is the system producing a signal for careful review, or is it effectively placing a person under suspicion?

In such cases, “human-in-the-loop” is not enough if the human is placed at the end of a pipeline that already framed the person in a particular way.

The question is not only whether a human clicks approve.

The question is whether the architecture preserved human dignity, proportionality and the right to challenge the system’s framing.

This is where enterprise architecture becomes inseparable from human judgement.

The architect’s new obligation

Enterprise architects have always worked with constraints: performance, cost, integration, security, scalability, maintainability, availability and compliance.

Those concerns remain.

But AI adds another obligation.

The architect must now design for the responsible movement of authority.

That means asking:

If these transitions are not designed, they will still happen. They will happen through interface defaults, user habits, vendor settings, incomplete controls, unclear ownership and organisational pressure to move faster.

That is how authority leaks.

The machine may begin as an assistant, but if its output is always accepted, rarely challenged and increasingly connected to execution, it becomes more than an assistant in practice.

Architecture must notice that shift before the organisation does.

That does not mean the architect becomes the moral owner of every business decision. It means architecture can no longer pretend that decision authority belongs only in policy documents and meeting rooms. Once AI is embedded inside business systems, authority also lives in prompts, permissions, semantic models, thresholds, user interfaces, escalation paths, audit trails and default actions.

Those design choices may look small.

Together, they decide how judgement moves.

What good architecture must now provide

In AI-enabled enterprise environments, architecture should provide more than access and integration.

It should provide:

Contestability

People should be able to question important AI recommendations without needing to become machine-learning specialists.

Traceability

The organisation should be able to reconstruct the path from evidence to recommendation to action.

Proportional autonomy

The degree of automation should match the risk, reversibility and human impact of the decision.

Semantic grounding

Recommendations should be connected to governed business definitions, not only raw data retrieval.

Role-aware authority

The system should understand who is asking, what they are allowed to see, what they are allowed to decide and what they must escalate.

Safe failure

When uncertainty is high, data is missing or policy conflicts exist, the system should slow down, escalate or refuse to overstate confidence.

Learning with accountability

Feedback should improve the system without erasing responsibility for the decisions already made.

These are not decorative controls. They are the conditions under which AI becomes fit for serious enterprise work.

The quiet danger of useful systems

The greatest risk may not come from obviously bad AI.

Bad AI is easier to reject.

The greater risk may come from systems that are useful enough to become trusted before the surrounding architecture is mature enough to deserve that trust.

That is the strange danger of progress. A tool that saves time can become part of the organisation’s judgement before the organisation has clearly defined what judgement it is willing to delegate.

A recommendation that appears hundreds of times inside daily work can become a new operating norm. People stop asking why it appears. They start asking why anyone would go against it.

At that point, the system has acquired authority.

Not through a board decision. Not through an explicit policy. Not through a philosophical debate.

Through repetition, convenience and confidence.

This is why architecture matters so much now.

It is one of the few disciplines capable of slowing down the invisible transfer of authority long enough for the organisation to see what it is doing.

The question that matters now

Enterprise AI will continue to advance. Models will improve. Agents will become more capable. Data platforms will make organisational knowledge easier to access through natural language. Business systems will increasingly combine retrieval, reasoning and action.

That future can be valuable.

But value will not come only from making machines more capable.

It will come from making organisations more clear about what those machines are allowed to influence.

The defining architectural question of the AI era is no longer merely:

Can the system produce an answer?

It is:

Who, or what, gave that answer the right to influence reality?

That question will not be answered by the model alone.

It will be answered by the architecture around it.

And ultimately, by the people willing to take responsibility for what that architecture allows.

The machine can recommend.

The architecture must answer.

Further context: This essay is original commentary shaped by practical enterprise architecture and data experience. It also sits within a broader industry movement: SAP is embedding AI assistants and agents into business workflows, Microsoft Fabric is making governed data more conversational through data agents, and AI risk frameworks such as the NIST AI Risk Management Framework and OECD AI Principles increasingly emphasise human oversight, accountability, transparency and traceability. The argument here is that enterprise architecture must now decide not only how information moves, but how machine-generated authority is bounded.