AI Governance in Practice: From Model Registration to Evidence

Practical AI governance begins by identifying each AI system, its owner, its purpose and the model dependencies behind it. It then turns policy into operating controls: permitted data and context, identity and role boundaries, deterministic checks, approval gates, security assessment and an execution record. A committee decision may authorise a use case, but only this chain shows what a particular run actually did.

You cannot govern an endpoint, application, model or agent that is not registered. Without a stable identity for the system, findings attach to a URL in a spreadsheet, ownership becomes ambiguous, and a model change can occur without a clear review trigger. Inventory is therefore not clerical preparation. It is the point where accountability becomes possible.

The terms describe different layers. An AI application is the user-facing or process-facing system. An endpoint is the reachable interface used for inference. A model is the versioned artefact behind that interface. An agent is an application pattern that can select or invoke tools within an assigned scope. Organisations may use different labels, and there is no mandatory universal taxonomy. The practical requirement is that the relationships are explicit enough to review.

Policy still matters. It states intent, risk appetite and authority. The gap appears when nothing connects that intent to runtime behaviour. The responsible AI position is made operational only when a workload's identity, permissions, decisions and evidence can be inspected together.

Start with a named record for the AI endpoint, application or agent. Assign an owner and environment, then connect the model and provider context available for that system. Where the model artefact is under direct control, preserve version and provenance information. Where it is reached through an endpoint, record enough context to identify the dependency used by the application.

Cerberus supports registration of OpenAI-compatible and HTTP-accessible endpoints, plus AI applications and agents that expose a reachable interface. Each registration can carry ownership, model, provider and environment context, with assessment history attached to the named system. This is the basis for posture management because findings and reviews no longer float independently of the asset they concern.

Registration should also establish purpose and boundaries. What business process does the system support? Which team owns changes? What environment does it run in? Is it an internal assistant, a public application or one step inside a larger workflow? These are governance facts, not an attempt to impose one taxonomy on every organisation.

Scope begins with information. Define what data may enter the prompt, what sources retrieval may search and what outputs may be retained. A broad identity permission does not automatically justify broad retrieval. The workload should receive only the context its approved purpose requires.

Then define authority. An AI step may interpret a document, classify a case or recommend a next action without owning the final system action. Consequential writes can remain behind deterministic validation or a named approval. This distinction lets teams use model interpretation without silently transferring operational authority to the model.

Human approval works best as part of execution rather than a separate inbox. The workflow pauses with the relevant context attached, a permitted reviewer decides, and the same run resumes or closes. The approver, decision and workflow version remain connected to what happened next.

AI governance is strongest when controls sit in the workflow path. The model handles interpretation. Rules + Code validate what can happen next. Identity and role-based access control determine who may invoke, edit or approve. Vault-backed secrets provide credentials without embedding them in prompts or code. A governed endpoint limits where inference is sent.

Deterministic checks can test required fields, thresholds, allow lists, expected formats and permitted target systems. They do not make the model more accurate. They constrain the action path around its output. If a check fails, the workflow can stop, take a correction branch or request human review rather than treating model output as authority.

This is the operating model described by governed AI automation: AI is one step inside a broader workflow of integrations, deterministic logic, approval and system action. The audit trail covers that complete chain, not merely the prompt and response.

Governance of use and security testing are complementary, but they are not the same discipline. Scope and approval answer who may use a system and what it may influence. Adversarial assessment asks how the application behaves when inputs are crafted to expose weaknesses in prompts, retrieval, tool use or information handling.

Nexus Cerberus provides AI Application Security and Posture Management. It runs scoped adversarial assessments against registered targets, organises test families against OWASP LLM Top 10 categories, and tags findings to MITRE ATLAS, the external adversarial threat framework for AI systems. These are mappings for security and risk analysis, not proof of a regulatory outcome.

Cerberus also builds an AI-BOM across model artefacts and software dependencies, including provenance, version and licence information, with unsafe serialised formats flagged. Findings are correlated with remediation guidance and can be delivered as signed PDF and JSON reports with an evidence bundle that recipients can verify offline.

Assessment should be repeated when the system changes materially or when the organisation's review policy requires it. A different model, tool scope, retrieval source or application path can change the surface under test. Cerberus assesses and reports on the application. It does not provision infrastructure or control the live execution path.

A reviewer needs more than a policy and an assessment report. For an operational run, the evidence chain can include the model and version used, the workflow and version, input and retrieved context where policy permits retention, the model output, deterministic check results, human approval where present, the final system action and the overall outcome.

Nexus keeps those steps in execution history inside the customer estate. Governance and audit connect versions, actors, approvals and results to the run they affected. Retention and visibility remain subject to the organisation's configured policy, particularly where prompts or retrieved context contain sensitive material.

Cerberus evidence serves a related but distinct purpose. Its signed reports and evidence bundles document a scoped security assessment and its findings. Workflow execution history documents what an operational process did. Together they can support a review, but neither should be presented as a certification or a substitute for the organisation's own legal, risk or assurance judgement.

Governance is not complete when the first approval is recorded. A model version changes, a workflow gains a new action, retrieval reaches a new data source, permissions expand or the intended use moves into a more consequential process. Each change can alter the system that was originally reviewed.

The loop does not imply automatic retraining or autonomous governance changes. A material change should create a review decision by the responsible owner. That decision may preserve the current scope, require new controls, initiate another assessment or stop use until evidence is sufficient.

Nexus Foundry is the platform's governance and self-service module. It publishes a governed catalogue across infrastructure, platform services, application services, workflows and AI agents. For AI governance, its role is to make an approved service requestable under defined options, entitlement and policy rather than leaving access to informal channels.

A guided request wizard captures structured input. Cost visibility can be shown before submission and approval. Policy-driven approval stages route the request to named authorities, and approved provisioning runs as a Nexus workflow. The request, decisions, provisioning steps and result remain in one execution record.

Foundry can also show adoption by department across services, workflows and AI agents through its Measure stage. That visibility can inform enablement and catalogue ownership. It is not employee scoring, and Foundry is not an AI security scanner. Security assessment remains the role of Cerberus.

Cerberus covers the security and posture side of the lifecycle. Its registry gives endpoints, applications and agents a stable identity with owner and environment context. Its AI-BOM provides a supply-chain view of model artefacts and dependencies. Its adversarial assessments produce findings mapped to OWASP LLM Top 10 categories and tagged to MITRE ATLAS.

The output is assessment and reporting: correlated findings, remediation guidance, a signed PDF and JSON report, and an evidence bundle. That material helps security, risk and engineering teams review an application against the organisation's controls. It remains distinct from workflow authority, provisioning and operational approval.

Keeping those roles separate prevents AI governance from collapsing into one tool category. Foundry governs requests and fulfilment. Nexus workflows govern operational execution and human authority. Cerberus assesses AI application security and posture. The organisation's governance model connects the resulting evidence.

Use these questions to connect policy, platform engineering, security and operational ownership. They remain useful regardless of which technology implements the controls.

1. 01

   Is every production AI application registered?

   A governance process cannot assign ownership, scope or review to a system it cannot identify.

2. 02

   Do we know which model and version it uses?

   The model dependency needs to be attributable when behaviour, risk or approval is reviewed later.

3. 03

   Is there a named owner?

   Someone must remain accountable for purpose, access, change decisions and remediation.

4. 04

   What data and retrieved context may it access?

   Define the information boundary before prompts and retrieval paths are connected to the workload.

5. 05

   What decisions can it influence?

   Separate interpretation or recommendation from the authority to perform a consequential system action.

6. 06

   Where is human approval mandatory?

   Place approval in the workflow where policy requires named authority before execution continues.

7. 07

   Are model and supply-chain dependencies known?

   Review artefact provenance, versions and software dependencies rather than treating the endpoint as a black box.

8. 08

   Has the application been tested adversarially?

   Assess the application within an explicit target, test-family, intensity and time window.

9. 09

   Are findings mapped to recognised frameworks?

   Consistent mapping helps security and risk teams discuss findings using shared external references.

10. 10

    Can we reconstruct the decision and action later?

    The record should connect model and workflow versions, permitted context, output, approval and final action.

11. 11

    What changes trigger re-review?

    Name material changes such as model, workflow, data source, permission or intended-use changes before they occur.