COBIT AI LLM Requirements: Write Testable Controls for Every Route

COBIT gives an enterprise a governance system for information and technology. An LLM deployment still needs its own requirements register. The register translates managed risk and data objectives into statements that an owner can implement. Quality, security, change, operations, and monitoring objectives add further requirements that an assessor can test.

I want to make that translation concrete for authenticated HTTP requests between users or agents and LLM endpoints. The result is a set of deployment requirements with acceptance evidence, rather than a list of COBIT objective names beside an architecture diagram.

TL;DR

• COBIT supplies governance and management objectives; the enterprise writes LLM requirements for each approved use case and route.
• Every requirement needs an owner and operating point. It also needs an acceptance test, retained artifact, and review trigger.
• Cover identity and authority, then prompt and response data. Add destinations, model changes, service operation, monitoring, and evidence.
• An inline gateway can enforce routed HTTP AI traffic. IAM and endpoint security need separate controls. Local execution, provider operations, model quality, and business decisions also sit elsewhere.

COBIT supplies the objective system

ISACA positions COBIT as a framework for governance and management of enterprise information and technology. Its core model organizes 40 objectives across Evaluate, Direct and Monitor; Align, Plan and Organize; Build, Acquire and Implement; Deliver, Service and Support; and Monitor, Evaluate and Assess.

The ISACA AI governance white paper applies those domains across the AI life cycle. EDM aligns AI with enterprise direction. APO establishes policies and risk processes, plus resources and data governance. BAI governs integration and testing, with validation and change included. DSS operates the deployed service. MEA evaluates performance and compliance while also addressing risk management and internal control.

That structure is the source of requirement topics. It is not a substitute for requirement wording. "Apply DSS05" tells an engineering team almost nothing about identity and content. The statement also omits destination, outcome, and evidence expected for one request.

The COBIT AI controls mapping maps objectives to control areas. This article takes the next step and shows how those areas become acceptance statements for an LLM deployment.

Each requirement needs five fields

Write each LLM requirement with five fields: accountable owner; applicable scope; required behavior; acceptance evidence; and review trigger. A sixth field can identify the COBIT objective that explains the governance purpose. This format keeps the objective mapping useful without turning the control register into a framework concordance.

Consider one destination rule for restricted customer data. "Sensitive customer data uses approved models" leaves the decision open to interpretation. A testable version reads: "The AI platform owner shall block a request classified as restricted customer data when its model destination falls outside the approved destination set for use case CS-17. Acceptance requires a synthetic denied request showing identity and classification, plus destination and policy version. Preserve the outcome and timestamp."

On the monitor, that test should produce a compact decision record with one green route and one red refusal. The requirement becomes visible in six or seven fields. A reviewer can reproduce it without convening the original project team.

My view: any LLM requirement containing the phrase "appropriate safeguards" should stay in draft until the author names the safeguard and owner, then supplies a failed test.

Governance requirements define authority and scope

EDM01, Ensured Governance Framework Setting and Maintenance, supports clear roles and accountability. EDM03, Ensured Risk Optimization, connects decisions to risk appetite. APO01, Managed I&T Management Framework, carries enterprise policy into management practice. For an LLM deployment, those objectives should produce explicit authority.

The use-case record should name the business owner and technical owner. Add privacy and security approvers where the use requires them. Legal, data, and model-risk review should have named people too. Define the approved purpose and users. List data classes and model destinations, then output uses and prohibited actions. Record the residual-risk authority and exception process.

Write the governance acceptance criteria in operational terms:

• the use case has a unique identifier and named owner;
• approval lists permitted users and roles, followed by data classes, destinations, and actions;
• prohibited uses appear in the same record;
• risk acceptance has an expiry or review date;
• policy exceptions identify an approver and reason, then define scope and end date;
• a material change reopens approval before production use.

The COBIT AI compliance checklist can sample these approvals across deployments. The LLM requirement register keeps the expected behavior precise for one system.

Identity requirements carry delegated authority

An authenticated request needs more than an API credential. The application should supply the user or agent identity and role behind the call, plus the approved use-case or workflow context. A shared service account may identify the application while hiding the person or agent whose authority matters.

Requirements at this layer should cover identity provenance and session binding. Define which issuer is trusted and which claims the policy decision uses. Add the limit on delegated authority. State the behavior for missing or expired identity context, plus malformed or conflicting claims. A fail-closed outcome is appropriate where policy depends on a claim that is absent.

A test should send the same synthetic prompt under two roles. The permitted role should reach the approved model, while the restricted role should receive a denial with a reason code. Preserve the request correlation identifier and policy version. The AI request authorization model describes the request fields that support this decision.

Identity proofing and credential issuance remain IAM responsibilities. MFA and account lifecycle stay there as well. The LLM requirement should reference those upstream controls and define the identity context required at the AI boundary.

Data requirements follow prompts and responses

The ISACA paper connects APO14, Managed Data, with metadata responsibilities, intellectual property, and protection of sensitive information. It assigns documented quality and safety practices to APO11, Managed Quality. For LLM systems, data requirements must follow direct prompts, retrieved context, system-added instructions, model responses, logs, evaluations, and retained feedback.

Create a data inventory for each use case. Name the source and owner of every class. Define permitted processing purpose and model destinations. Specify the required minimization and redaction behavior. Add retention and access rules, then deletion and integrity requirements. Generated output needs classification because it may reproduce sensitive input or create a consequential assertion about a person.

The runtime requirement should connect classification to action. Restricted source code may use one private model route and trigger a block on a public SaaS route. Personal data may require redaction or an approved regional endpoint. A response containing a prohibited class may require masking before delivery.

AI data classification provides the categories that can make these rules executable. Acceptance evidence should include seeded prompt and response samples for each material class, with the exact policy outcome retained.

Security requirements act before forwarding

DSS05, Managed Security Services, supports security protocols for AI systems. BAI09, Managed Assets, supports the infrastructure that houses AI workloads. Translate those objectives into controls on the actual request path and surrounding service.

For routed HTTP AI traffic, define permitted providers and endpoints. Add models and methods, followed by data classes. Require TLS and approved authentication to the provider. Set explicit payload limits, dependency timeouts, and corresponding failure behavior. Define rate controls and the behavior for policy-engine or classification failure. Record how prompt injection indicators affect connected workflows. Specify response inspection where data policy applies to generated content.

Operational security also covers secrets and network routes. Dependency management and administrative access require controls, along with logging destinations. Those controls may sit beside the gateway rather than inside it. Keep the requirement owner aligned with the enforcement point.

Each blocking rule needs a negative test using synthetic data. Each permitted path needs a positive test. A screenshot of configuration supports review, but the transaction record proves that the control acted at the boundary. Link both artifacts to the same requirement identifier.

Change requirements cover models and policy

The ISACA paper maps BAI06, Managed IT Changes, to structured handling of model and algorithm updates. LLM deployments change through provider releases and model aliases. System prompts and retrieval sources change too. Tools, routing logic, policy versions, and classification rules complete the change surface. Treat each material change as a control event.

The register should define which changes require testing and approval. A new provider requires security and privacy review, followed by legal and data review. Model version changes may require quality and safety evaluation. Adding a connector changes the accessible data and actions. Policy revisions need a versioned change record and regression tests. Routing updates may alter destination region or provider terms.

Require rollback criteria and an owner. Preserve the previous approved version and deployment timestamp. Attach test results to the change. Verify that the production decision record identifies the new version after release.

Emergency changes deserve the same evidence after deployment, with a short review deadline defined by the enterprise change process. A permanent "temporary" exception creates invisible scope and should appear as an expired item in monitoring.

Operations requirements define service behavior

The DSS domain governs the day-to-day operation and support of deployed systems. For an LLM route, define availability and continuity requirements. Add queue and timeout behavior, incident intake, access to decision evidence, and recovery after failure. Include the owner who receives a policy escalation or failed route.

A fail-closed design can still need differentiated behavior. Failure of the restricted-data classification service may block the request. Low-risk internal drafting may route to a controlled fallback after approval. Write the expected outcome for each dependency and risk class instead of relying on a global label.

Operational records should connect a transaction to service events. Preserve the correlation identifier and timestamp. Include identity and route, plus the model and policy version. Add the classification result and enforcement outcome. Join that record to incident or change systems without copying sensitive payloads into tools that lack approval for them.

Service continuity for the application and provider sits outside an inline policy decision. The requirements register should still link those dependencies so that a reviewer can follow a failed request into the responsible operating process.

Monitoring requirements test control effectiveness

MEA01, Managed Performance and Conformance Monitoring, supports monitoring targets. MEA02, Managed System of Internal Control, tests whether the required safeguards remain embedded in operations. Applicable obligations connect to the deployment through MEA03, Managed Compliance with External Requirements.

Choose measures that reveal control behavior. Track missing identity context and blocked destinations. Sample permits for correct classification and policy version. Review exception age and expired approvals. Measure route bypasses and evidence gaps. Add classification reversals and policy changes without matching tests. Include output-quality measures where the use case relies on generated assertions.

Monitoring needs thresholds and response owners. A count of denied prompts shows activity. The percentage of sampled decisions with complete evidence says more about control operation. A repeated false positive should open a tuning change; a missed restricted payload should open a control defect and risk review.

Retain monitoring reports with source queries and review sign-off. The next assessor should be able to reproduce the sample and trace each finding into remediation. The final record should show acceptance or closure.

Evidence requirements preserve the decision

A requirement is auditable when the evidence shows the control acted on the scoped system. For each sampled HTTP request, preserve the correlation identifier and authenticated identity supplied by the application. Add the role and use-case context, followed by prompt and response classification. Record the provider and model destination. Include policy version and outcome, then the timestamp, record integrity, and storage location.

Keep the record outside the calling application's exclusive write path where independent evidence matters. The application can still log business context, but the enforcement decision should have its own evidence source. Join the application record and enforcement decision by a common identifier.

Vendor documents belong in the package too. They support provider controls and retention, along with deployment and service commitments. They provide no transaction-level proof about the enterprise's authorization decision. Keep provider evidence separate from enterprise configuration and request evidence so reviewers can see the source of each claim.

The acceptance package should contain one successful request and one refusal. It should also contain current configuration and approval, plus the related change records. A short evidence index saves hours during the audit and exposes missing artifacts before a regulator or customer asks.

The architecture boundary belongs in every requirement set

These requirements cover authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. An inline layer can evaluate application-supplied identity and content classification. Model destination and policy complete the decision before forwarding. The layer can inspect returned HTTP content and create a decision record.

IAM owns identity issuance and account lifecycle. Endpoint tools cover compromised devices and local processes. STDIO tool calls and local inference bypass the route. Provider evidence covers model development and training, plus internal access and service operations. The consuming application owns source permissions and output truth. Human review and business action remain there too. Network and application controls must detect direct calls that bypass the approved path.

Put those boundaries in the control register beside the in-scope routes. Clear exclusions prevent a policy gateway from receiving credit for work performed elsewhere and prevent uncovered paths from disappearing between teams.

DeepInspect

DeepInspect provides an independent policy decision for authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It evaluates application-supplied identity and role with content classification. Model authorization and versioned organizational policy complete the decision before DeepInspect forwards a request or returns a response.

Each decision produces a signed, tamper-evident record outside the calling application's write path. That record can satisfy acceptance-evidence requirements for the routed control and give MEA02 a stable object to sample. DeepInspect leaves use-case approval and IAM with the enterprise. Provider due diligence and local execution remain there too, along with model evaluation, source-data quality, and downstream business decisions.

Book a technical deep dive at deepinspect.ai.