LEARN. PRACTICE. GROW.Inventory the solution, not just the model
An enterprise assistant combines more than a language model. In the fictional example, it reads runbooks, searches an index, drafts tickets and consults approval rules. Inventory should identify these components, versions, data, owners and capabilities. A connector update can widen authority without changing the model name or interface appearance. Governance should follow the integrated system through acquisition, configuration, use, change and retirement. First define the authorized use case: helping draft a proposal in test is different from executing a production change. Identify expected benefits, affected people, error consequences, stop conditions and who decides scope changes. AI policy should become observable requirements, including permitted data, permissions, human review and communication of limitations. The AI RMF supplies governance, mapping, measurement and management functions to organize this work; it does not automatically certify the solution. In the project plan, connect each risk to a decision and required evidence. Distinguish what was rehearsed locally, what the supplier asserted and what still needs validation in the target environment. Keeping those categories separate prevents a convincing demonstration from being confused with operational readiness, especially when deployment adds capabilities absent from the initial pilot.
Separate threats to choose controls
AI threats act at different stages and on different objects. Altering examples before tuning is training-data poisoning; trying to influence an execution through received text is another path. Inferring sensitive attributes associated with data is an inversion objective, while building a functional replica seeks to extract model capabilities. None of these descriptions should become an automatic label without evidence. Record what was observed, where the change occurred and which objective the exercise investigates. In an application searching runbooks, the index is also a data store. Stale classification can permit retrieving a chunk after its original document becomes restricted. Current access policy should govern retrieval and handling of copies. A malicious instruction inside a document must not grant authority to a tool. Input filters can reduce exposure in tested cases, but ten blocked inputs do not establish that every future manipulation will fail. Output controls, permissions and destination validation remain necessary. In our Python model, text is only a string with no interpreter: its inability to change permissions demonstrates local separation between data and rules, not an LLM’s resistance to prompt injection. This limitation should accompany every presentation of the results.
Authority and approval bound to content
The lab use case permits only creating a draft change in test. Its plan contains ticket, tenant, environment, tool, model version, data classification and cost units. Approval stores a canonical digest of those parameters and the approver’s identity. Before recording a synthetic draft, the program compares the plan and checks expiry, current authority and policy version. Changing T7 to T9 breaks the match; changing the environment to production also violates permitted scope. JSON field order does not change the digest, but an argument change does. This explains why a phrase such as “approved for today” is insufficient for different actions. Approval should refer to the specific operation, and the target should enforce authorization independently of generated output. In the model, approval is single-use and revoking the approver prevents execution. These are local checks over fixture-supplied identities. There is no cryptographic approval signature, corporate authentication or durable storage. A restarted process would lose state, and concurrency was not exercised. For a real connector, the team would need an implementation preserving these properties, including atomicity between checking and execution, and tests within its authorized operating context.
Run and interpret the original model
The run.py file executes risk arithmetic and a local decision state machine without network or external services. Run it with Python and an output path for evidence.json; repeat using another name to retain both observations. Its 34 checks include expected benefit, conditional probability, ticket and environment changes, restricted classification, a new version, missing approval, revocation and expiry. Logical time starts at 1000 and approval expires at 1100: it can remain valid at 1099 but is expired at 1100. These values are exercise inputs, not elapsed seconds measured in a service. The budget uses abstract units: 80 are consumed against a limit of 100. An approved plan requesting 20 reaches the boundary and passes; an approved plan requesting 21 is denied without changing drafts, consumption or used approvals. Data classification and identities are trusted fixture inputs, not automated inspection results. The report retains Python version, script hash and each check’s outcome. Both observed runs passed 34 checks each. This demonstrates this model’s implementation and exercised cases; it does not validate supplier pricing, AI performance, legal policy, enterprise integration or protection against unknown attacks.
Representative evaluation and workable human review
A result obtained on the same examples used to tune a system can overstate its ability to handle new incidents. Prepare separate cases representative of APS work, including incomplete instructions, outdated documents, conflicting sources and situations where the correct response is to request further investigation. Define criteria before evaluating. A fluent explanation or plausible citation title does not prove correctness; the exercise requires comparing recommendations against logs and documents that actually exist. Retain failures and version differences instead of preserving only favorable demonstrations. Human review needs workable conditions. If the pilot proposes four hundred actions per hour and the shift can properly review only thirty, an approval button does not resolve that gap. Consider volume, presented context, time, ability to reject and queue handling. Automatic approval through silence changes the control and should be assessed accordingly. The local model denies proposals when declared proposal rate exceeds declared capacity; it does not measure actual human productivity. In a project, an authorized user and task rehearsal would need to show that the process is workable. Keep generalization limits visible and do not turn a rate observed in a small sample into a universal effectiveness promise.
Controlled change, suspension and retirement
RUN handover should define who monitors behavior and who can suspend capabilities. In the fictional example, a pilot limit is exceeded after a model update. An unchanged interface does not establish unchanged behavior. Trigger the agreed suspension process, preserve evidence and reassess before resuming. Raising the limit so the result passes can represent a new risk decision, but it should neither erase the failure nor be presented as uninterrupted conformance. Rollback also needs compatibility with current connectors, data and policies. At retirement, disabling the page does not remove the index, tokens, jobs or evaluation copies. Identify remaining components, revoke capabilities without an authorized purpose and apply retention rules or documented exceptions to each copy. Keep enough evidence to reconstruct decisions without unnecessarily storing restricted documents in logs. The lab records only plan digest, outcome, reasons and logical time; this reduces persisted content but is not an enterprise audit architecture. Before closing the project, confirm contacts, incident criteria, rollback and review responsibilities. This course’s examples and models are original and fictional: they do not represent BNP Paribas procedures or award participants an official certification. Production acceptance remains a separate organizational decision.
python3 content/labs/securityx-governance-contracts/run.py --output /tmp/securityx-governance-evidence.json
python3 content/labs/securityx-governance-contracts/run.py --output /tmp/securityx-governance-evidence-repeat.jsonA plan approved for T7 in test does not authorize T9 in production; reject the change before any effect.
Common pitfalls
Prompt as authorization control; source title as evidence; button as effective review; local model as actual AI execution.
Related topics: Governance, risk, and exceptions · Suppliers, data, and threats
Generated output can propose; authority, evidence and acceptance belong to verifiable processes.
Reference: Artificial Intelligence Risk Management Framework · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17