Who is accountable when AI is deployed without a formal decision or review?

When AI Reaches Production Without a Formal Approval Trail

Accountability does not disappear because a model, embedded feature, or workflow was switched on by default. The organisation remains responsible for the decision environment that allowed an AI capability to operate without review, including who owned the use case, who assessed the risk, and who signed off on the release path. That matters because unreviewed AI can affect data handling, user trust, operational decisions, and regulatory exposure even when nobody intended a “deployment.”

For security and governance teams, the issue is usually not whether the tool was technically available, but whether the organisation can prove it understood the use, approved the boundary, and assigned ownership before production use. The governance gap becomes visible when inventory, approval records, and risk acceptance do not line up with what is actually running. In practice, many security teams encounter this only after an unexpected workflow, data exposure, or audit question forces them to reconstruct the approval path retroactively.

For a control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it treats authorisation, accountability, monitoring, and traceability as operational requirements rather than informal intent.

How Organisations Show Ownership When Formal Review Is Missing

In practice, accountability is usually assigned to the organisation first, then to the internal function that should have controlled the change. That may be product leadership, application ownership, platform operations, a risk committee, or a governance function, depending on how the AI capability entered production. The key question is not who built the model, but who had authority to let it operate and who was responsible for preventing an unreviewed capability from becoming part of business process.

This is why “shadow AI” and default-enabled features are governance problems as much as technical ones. If a team can enable an AI feature through a platform setting, plugin, connector, or vendor default without a documented review, then the organisation needs to treat that as a control failure in intake and change management. Ownership should cover the full path:

• what the AI system or feature is used for
• which data it can access or generate
• who approved the use in that context
• what monitoring exists after go-live
• who can suspend or remove it if the use changes

Formal review is not only about model quality or safety testing. It is also about ensuring the organisation can explain why the AI use was acceptable in that setting, whether the decision was explicit, and whether the operating team understood the residual risk. Where those answers are missing, accountability becomes diffuse, but the governance obligation remains with the organisation that allowed the deployment path to exist. This guidance breaks down when the AI capability is inherited through a third party and the organisation has no practical control over configuration, logging, or disablement.

Where This Question Turns into a Governance Failure

Tighter AI oversight often slows adoption, requiring organisations to balance speed of release against the ability to prove approval, ownership, and review. That tradeoff becomes most visible in exceptions, pilots, and vendor-provided defaults, where teams may assume low-risk use and skip the formal gate.

One edge case is a feature that is “available” but not actively promoted. If it can process business data, influence user actions, or change records, it still needs an accountable owner even if it was enabled as part of a standard product update. Another edge case is a small internal pilot that later becomes embedded in production workflows without being reclassified. In governance terms, the absence of a formal decision is itself a decision problem, because it means no one can show where acceptance of the risk occurred.

The same issue applies when multiple teams share responsibility. Vendor management may review contract terms, security may assess technical exposure, and the business may own the use case, but the organisation still needs a single decision path that ties those views together. Guidance is consistent here: approval should be explicit before production use; consensus is weaker on whether that approval must sit with a central AI board or with delegated business ownership, provided the decision is documented and auditable. The common failure is treating “nobody objected” as the same thing as formal authorisation.

Practitioner Guidance

What to prioritise: Establish who can actually approve AI use in production, then verify that this authority matches the system’s real data access and business impact. If the approval path cannot be named quickly, the control is not mature enough for routine reliance.

What to verify: Confirm that the record of ownership covers the use case, the deployment path, and the operational owner after go-live. Teams should be able to show who accepted the risk, what was reviewed, and what would trigger suspension or rollback.

Practitioner takeaway: When AI is deployed without formal review, the most important question is not who pressed the button, but whether the organisation can still prove a defensible decision path and name the owner who would be accountable if the use proves unsafe or noncompliant.

Related resources from NHI Mgmt Group

• What breaks when an AI agent is deployed without formal ownership?
• Who is accountable when an AI model fails a regulated decision review?
• What breaks when agentic AI is deployed without formal security policies?
• Who is accountable when a high-risk SaaS or AI tool is used without documented purpose or review?