AI placement: An engineering decision you can no longer ignore

AI placement changes the risk profile. The same model can operate as a lower-risk design-time accelerator or a higher-risk execution-path agentic system with authority to act.

How placement changes the system

Placement changes both the software and the human organization around it.

Take a simple example. If an engineer queries a database directly, the path is clear. They inspect the schema, write SQL, validate the result, version the logic, and repeat. The database is deterministic. The work is inspectable.

Now place AI between the engineer and the database to execute the same task, end to end. The database has not changed, but the path through it has.

There is now an interpretive layer between intent and execution. Something in the middle is now deciding what the user meant, how to query the database, and how to interpret the results. This introduces ambiguity through interpretation and removes the ability to fully verify or predict the path from intent to execution before it runs.

This is powerful, but its speed and ease can bypass engineering judgment.

Now place AI elsewhere and the risk profile changes entirely. An engineer might say, "Look at this schema. I want to check X. Draft the SQL for me." Here, AI is not in the live execution path. It acts as a design-time accelerator. The output is reviewed, corrected, versioned and owned. What enters the execution path remains a deterministic artifact.

Same model. Same task. Different placement. Different system.

Speed without discipline or design-time acceleration?

AI works well when it accelerates thinking rather than replacing it.

An engineer reviewing a test approach might use AI to surface gaps, edge cases and untested assumptions. They walk through the solution, add constraints, review the output, keep what matters, and discard the rest. But this only pays off if review is substantive, time-boxed, accountable and willing to say no.

Plausible output is the risk. "Looks good enough" becomes the default. Assumptions make an early entry. Defects surface later, where they cost more to identify and fix, and ownership is harder to establish.

The important thing to note about drift is that it rarely announces itself in a review. Instead it appears in production.

Language: A key factor in the control surface

When AI sits inside a workflow, natural language becomes part of the control surface governing what the system does next. Wording shapes behavior, how ambiguity is handled, how much the model infers, and how far it moves beyond the user's intent. This applies to prompts, agent instructions, tool policies, test harnesses and model-facing configuration.

The risk is not only factual error. It is interpretive overreach.

The model does not need to invent wildly to cause harm. A plausible extension of the request is enough. Close enough to feel right, wrong enough to create a defect. The answer sounds authoritative, even when it has moved past what the user meant, making drift harder to detect. This is why placement matters more than prompt polish. The industry is calling this context engineering, but does that go far enough?

AI: Not just another abstraction

Programming languages, APIs, frameworks and platforms hide detail. They are not perfect, but their uncertainty is bounded. Interfaces, types, contracts and tests constrain what the abstraction can and cannot do. Decades of practice have built assurance habits around these boundaries.

AI does not only hide implementation. It interprets meaning. It also introduces a different risk shape — one that does not sit neatly inside the assurance habits that engineering teams have already built. The issue is not abstraction itself. It is what kind of abstraction you are adding, where you add it, and what authority it has once it is there.

How agents multiply placement decisions

In a single-model interaction, the human boundary is usually clear.

A person asks for output. A person reviews it. A person accepts, rejects, or changes it. A person owns the decision.

Agentic systems make this harder.

When agents plan, call tools, and revise across a long run, placement stops being a single decision. It becomes a property of the system. The interpretive layer moves through stages, taking different shapes as it plans, acts and commits. Each tool call is a placement decision. Each autonomous action is a commitment made before a human sees the result.

By the time a final answer surfaces, the meaningful decisions may sit several steps back, inside a planning step that nobody was watching.

In April 2026, one widely discussed incident report described an AI coding agent encountering a credential mismatch in a staging environment. It decided to fix the problem, found an API token in an unrelated file, used it to call the infrastructure API, and deleted the production database and volume-level backups in nine seconds. As reported, the agent said it had guessed rather than verified, and that it executed a destructive action without an explicit request.

The placement decisions that made the incident possible happened long before those nine seconds. The agent had the rights and access to resolve credential errors. A token with broad permissions sat somewhere reachable. Infrastructure allowed destructive operations after authentication, without any additional confirmation. The deletion was where the consequence surfaced. This outcome reflects where authority had been placed in the system, and what it was allowed to do without verification before it acted.

Guardrails start with placement

Governance is not a catalog of controls applied after the system is built. It is a set of placement choices made while building it.

Where should AI assist? When should it decide? When should it pause? Where must a named human approve the next action before execution continues?

Some actions need a human boundary before they happen, not because AI should never be trusted, but because some commitments are irreversible and some contexts are too ambiguous, requiring ownership to be explicit before the fact, not assigned afterwards.

This is not only a limitation of current models. It is a property of consequential systems.

Engineering has always needed human judgment at certain decision points. Agents make it easier to remove those points without noticing. This is the governance risk of AI systems.

A system already full of ambiguity

AI does not arrive in clean, well-specified systems.

Organizations already run on human interpretation. Requirements get negotiated. Assumptions are filled in socially. Tacit knowledge carries more of delivery than anyone documents. Technical and non-technical teams translate for each other constantly. Much of this translation stays invisible until it breaks.

AI enters that existing layer of ambiguity.

That does not make AI interpretation equivalent to human interpretation. Humans bring judgment, context, social accountability, and the ability to be answerable for decisions. AI does not inherit those structures on its own.

In practice, when AI enters a workflow that already depends on informal interpretation, it does not replace ambiguity with precision. It adds a new interpretive layer without inheriting human judgment or accountability structures. This is why engineering teams need to decide deliberately where AI sits, what it is allowed to do, and how its actions are controlled.

The higher the consequence, the more important it is that accountability is real rather than nominal.

Named accountability is not always real accountability. In multi-supplier delivery, ownership often lands with someone who lacks the context, authority or time to exercise it. That is accountability in name only. A placement decision is not only about who owns the outcome. It is about whether that ownership is real.

If you cannot observe it, you cannot govern it

The test is whether teams can see, explain and control how outcomes are produced, and who has approved each consequential step — a system or a human.

For a system to be governable, teams need visibility of inputs, outputs, actions and approval boundaries at each meaningful step. If those points are invisible, the system is not being managed or controlled. It is being trusted by default.

The constraint is whether there is enough visibility to understand and control those placement decisions and their impact.

The growing gap

The risk is that autonomy is accelerating beyond a team’s ability to observe, audit and control. The teams that actively manage this gap will keep accelerating with control. The teams that ignore it will eventually lose the ability to explain or control their own systems. This is not usually through one major incident, but through the accumulation of small failures that nobody can fully explain or reconstruct.

If AI is placed in a position where it can take irreversible action without pre-execution verification, the system is no longer fully testable or controllable.

This applies directly to systems where AI can modify production data, influence deployment pipelines, generate test logic or resolve infrastructure issues without pre-execution verification, including cases where AI-generated tests validate the same assumptions used to generate the code and remove independent verification of correctness.

Practical rules for AI placement

Heuristics that support your placement decisions:

• Design-time: Use AI to draft ideas, tests, documents and code, then require real human review before merge.
• Execution-path: Restrict AI to reversible actions by default. Treat irreversible actions, such as deletion, credential rotation, deployment and data migration as approval-gated.
• Permissions: Apply least privilege. Avoid long-lived or broadly scoped tokens in places agents have access to.
• Step-up controls: Require explicit confirmation for destructive operations, ideally through a different identity or second party.
• Observability: Log prompts, inputs, tool calls, outputs and human approval decisions at each meaningful step.
• Blast radius: Create a sandbox by environment and scope. Make wrong actions safe to fail in staging.

If these constraints are not explicit in your system, they are being assumed. Assumption is not control.

What engineering teams need to do next

Placed well, AI helps teams move faster without losing control. Placed poorly, it hides uncertainty inside the system and makes outcomes harder to explain, govern, and take ownership of. This risk grows when AI appears in workflows outside formal oversight: Shadow AI, where placement decisions are being made without anyone recognizing them as such.

Prompting still matters. But prompting is not the core engineering decision. Placement is. Placement judgment means deciding where uncertainty belongs, who owns it, and how visible it remains. Not whether AI is used, but whether unverified interpretation is allowed to act.

Here are some questions that need to be asked when designing or reviewing AI placement decisions:

• Where does AI sit in the workflow?
• What authority does it have?
• What uncertainty does it introduce?
• What evidence does it leave behind?
• What must be reviewed before the system acts?
• Who owns the result when it fails?
• Is that ownership real?

Placement decisions are already being made, consciously or not. The question is whether you can still see, test, and control the consequences before the system acts.

>> Connect with me and let’s talk about quality engineering, test strategies and how AI changes risk, control and accountability in your complex business environment.

Posted: 18/06/26