AI design-table gap

The distance between business-led AI adoption and security’s ability to influence architecture and access decisions. This gap matters because it lets permissions, data sources, and accountability be set before governance is in place, creating compounding exposure.

Expanded Definition

The AI design-table gap describes a governance and security timing problem, not a technical flaw in the model itself. It appears when AI programmes move from concept to build faster than security, privacy, legal, and identity teams can shape the architecture, data pathways, and access model. In practice, the “design table” is where choices about training data, system prompts, tool access, logging, retention, and human oversight should be made before deployment hardens those decisions. Once those choices are embedded, reversing them is slower and more disruptive.

For NHI Management Group, the key distinction is that this gap is about influence at the point of design, while related issues such as poor access control or weak data governance are downstream consequences. The term also intersects with agentic AI security because agents often require tool permissions and credentialed access early in the lifecycle. Authoritative control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls help translate that early design influence into concrete control expectations.

The most common misapplication is treating the AI design-table gap as an implementation delay, which occurs when teams notice the problem only after the system has already been integrated with live data and production access.

Examples and Use Cases

Implementing AI governance at the design table rigorously often introduces coordination overhead, requiring organisations to weigh faster delivery against stronger control over risk-bearing decisions.

• A business unit approves a customer-support agent before security reviews what systems the agent can query, creating a permissions model that is hard to unwind later.
• An internal AI assistant is designed with broad retrieval access to shared drives, but data classification and retention rules are not defined until after launch.
• A software team selects a third-party model and tool stack before identity and access teams decide whether human approvals, scoped tokens, or OWASP guidance for LLM and agent risks should govern tool use.
• A regulated organisation records model outputs for auditability, but logging requirements were not set early enough to ensure the logs are complete, consistent, and privacy-aligned.
• An AI procurement process accepts vendor architecture as fixed, so security can only review controls after contractual and technical commitments are already made.

These scenarios are common because AI delivery often starts with a use case and a pilot, while governance enters later as a review step rather than a design input. In maturity terms, the gap is widest when architecture decisions are made by product, data, or engineering teams without a formal security gate tied to identity, secrets, and tool access.

Why It Matters for Security Teams

The AI design-table gap matters because security that arrives after architecture decisions rarely gets full leverage. If data sources, access scopes, and logging defaults are already set, security teams may end up compensating with monitoring and exception handling instead of shaping the system to be safer from the start. That creates brittle controls, inconsistent accountability, and higher exposure to prompt injection, misuse of secrets, over-privileged agents, and unintended data exposure.

This is especially relevant where AI systems behave more like operational entities than static software. Agentic workflows can request access, call tools, and act on behalf of users, which makes early decisions about identity, authorisation, and supervision critical. Guidance from OWASP and control families in NIST help teams anchor those decisions before deployment. A strong design-table process also supports traceability for accountability, which becomes essential when multiple teams share responsibility for model behaviour and downstream actions.

Organisations typically encounter the consequences only after an AI system has been launched with excessive access, incomplete logging, or unclear ownership, at which point the AI design-table gap becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do AI agents create an attribution gap in IAM?
• Why does embedded AI in SaaS create a governance gap?
• When should organisations move from policy design to runtime enforcement for AI systems?
• Why do AI agents complicate least-privilege design?