Production AI does not mean the maturity work is finished.

Review four connected areas separately

GlobalLinc uses Policy, Visibility, Governance, and Optimization to organize the conversation. This is an advisory structure, not a maturity certification or a requirement to complete four projects in order. NIST’s separate AI Risk Management Framework also treats governance and risk management as ongoing work across the lifecycle.

Sources [1]

Start with one representative workload

Choose a live workload that matters to the business and has an accountable owner. Include the business process it supports, not just the model endpoint. Map the user request through retrieval, model calls, connected systems, the resulting output or action, and the people who rely on it.

Record what happens when the application has insufficient information, encounters a service error, or receives a request outside its purpose. An impressive demonstration can conceal those everyday cases. Agree on the specific decision the review needs to support, such as expanding access, adding a tool, or changing a model.

Check the foundation behind the application

The joint secure-deployment guidance published by the UK NCSC and international partners emphasizes infrastructure protection, access control, evaluation, and incident readiness. Use those principles to ask for evidence from your environment.

• Ownership: a business owner accepts the outcome, a technical owner manages releases, and someone receives and acts on alerts.
• Identity: users and services authenticate appropriately; credentials have defined ownership, storage, rotation, and revocation.
• Data access: retrieval and downstream systems enforce the intended scope, including tests with different user roles.
• Environments: development, testing, and production have suitable boundaries for code, credentials, and sensitive data.
• Release evidence: the deployed prompt, model, retrieval setup, and tool configuration can be identified and compared with a known working version.
• Failure handling: timeouts, a safe fallback, recovery steps, and the limits of rollback are documented and exercised.

Sources [2]

Review what connected AI can actually do

A read-only assistant and an agent that changes a business record need different controls. OWASP describes excessive agency in terms of too much functionality, permission, or autonomy. Review tools individually and authorize only the records and actions the workflow requires.

External documents, messages, or websites can contain instructions designed to redirect the application. OWASP’s prompt-injection guidance supports layered controls, limited privileges, and human approval of high-risk actions. Define which system enforces each boundary, then test an attempted action outside the permitted scope. A filter, gateway, or system instruction is one layer; authorization must also hold at the connected system.

Sources [3] [4]

Test the whole task before changing it

Keep a representative set of ordinary requests, edge cases, missing information, and failures. Define an acceptable result with the people doing the work. Check whether answers are supported by the intended evidence, whether connected actions are correct, and whether users can complete the business task.

NIST’s ARIA evaluation approach combines model testing, adversarial testing, and user testing. That distinction is useful when planning a review: a good answer in a controlled test does not establish that misuse is contained or that the workflow serves the people relying on it. Select the tests around the consequences of failure in your application.

Re-run relevant checks when prompts, models, data sources, permissions, or tools change. The NCSC’s operational guidance specifically recognizes that changes to data and prompts can change system behavior. Monitor production for patterns your test set missed, while limiting access to sensitive logs and setting appropriate retention.

Sources [5] [6]

Example: a helpful assistant gains a new action

Illustrative scenario: a service assistant answers questions from an approved set of manuals. The team proposes allowing it to update a work order. Its existing answer tests may still pass, yet they do not establish which work orders it may change or how a mistaken update will be corrected.

Before enabling the action, identify the permitted fields and records, test permissions for different roles, require approval for the changes that warrant it, and verify the audit trail. A model rollback will not automatically reverse a work order already changed. This is a focused governance and application review, even if the original assistant is performing well.

Prioritize gaps by consequence and evidence

Keep a short register with the finding, supporting evidence, coverage limit, potential consequence, owner, and next action. Mark an untested control as unknown. A blank field should not quietly become a passing result.

A critical access or action-control gap may need attention before expanding use. Other work can be sequenced around operating priorities. Avoid compressing the review into a single maturity score that hides one important unresolved issue.

Preserve the operating model that works

Bring your internal application and cloud owners, security lead, business owner, and existing providers where relevant. Use current diagrams, authorized configuration exports, release records, evaluations, and a representative cost period. Share sensitive evidence through an agreed channel.

The result should be a decision and a realistic improvement plan. GlobalLinc can help define the review and bring in the specialist expertise needed for a particular architecture, control, or workload question alongside the team you already have.