A policy may say that an AI assistant can draft a response but cannot send it. The architecture review is where the team can demonstrate whether that boundary actually holds.

NIST SP 800-218A extends the Secure Software Development Framework with practices and considerations for generative AI and dual-use foundation models. It provides a development-security reference, not a guarantee that a particular deployment is safe or compliant. Read NIST SP 800-218A.

Walk through a realistic request

A useful review exercise is to trace one request from the user to the final action. Identify the documents retrieved, the services called, the credentials used, and the points where information or authority crosses a boundary.

Then ask the team to demonstrate an exception: a request for a restricted document, an unavailable dependency, or an attempted action outside the assistant’s approved purpose.

Make policy statements testable

The following are suggested review questions, not a claim that any one control is sufficient:

• Access: Can the assistant retrieve information that the requesting user cannot access?
• Actions: Which connected tools can change records, send messages, or start transactions?
• Approval: Where a person must approve an action, what prevents that step from being bypassed?
• Evidence: What records help a reviewer reconstruct a disputed action?
• Recovery: How can the team disable a capability and continue the business process?

An illustrative example

Consider a support assistant intended only to suggest replies. A review could ask the team to show that its service account lacks permission to send messages. If the business later requests automatic sending, that becomes a distinct design decision with new evidence to assess.

This example illustrates the review approach; it does not describe a client engagement or tested product.

Leave with decisions and evidence

The review output should state the approved purpose, unresolved design questions, demonstrations completed, and conditions for the next change. That makes the architecture discussion useful to both technical teams and the leaders accountable for deployment.

Discuss your AI governance questions with StrategyAI Partners.

Back to Insights

An AI inventory becomes useful when someone can use it to decide what needs attention next. A list of vendor names alone rarely provides enough context for that discussion.

NIST AI RMF 1.0 includes inventory mechanisms under GOVERN 1.6 and connects risk management with understanding an AI system’s context, measuring risks, and prioritizing responses. These are related functions, not a mandatory linear checklist. Read the NIST AI RMF Core.

Start with one workflow

For a practical first exercise, choose a business process that already uses AI. Interview the person responsible for the process and ask them to walk through a recent example. Record what the tool actually does, rather than relying only on the purchase description.

A useful working record could include:

• The business purpose and current deployment stage.
• The people using the output and the actions it informs.
• The data sources and connected tools.
• The business and technical contacts.
• The evidence available for review and the questions still unanswered.

Separate a finding from an assumption

“No approval record was provided” is different from “no approval occurred.” Preserve that distinction. Record what was reviewed, what was missing, and who can resolve the uncertainty.

For example, an illustrative review of an internal writing assistant might find a documented access policy but no evidence that document permissions were tested. The next task would be to obtain or perform that test, with a named owner and an agreed scope.

Turn the inventory into a work queue

Group the next actions by the decision they support. Some questions may need an immediate answer before expansion; others may be appropriate for a scheduled review. Explain the basis for each priority rather than presenting an unexplained score.

For every action, specify the owner, due date, expected evidence, and decision that follows. That gives the inventory a practical role in the organization’s ongoing work.

A useful first output

Start with a short register of systems and a separate action list. Expand the detail when it helps someone make a better decision, rather than treating completeness as a substitute for progress.

Discuss your AI governance questions with StrategyAI Partners.

Back to Insights

An AI briefing should leave leadership with a decision to make. A list of pilots, tools, or training sessions does not show whether the organization understands the consequences of expanding their use.

NIST’s AI RMF Playbook connects governance with documented responsibilities, organizational risk priorities, and review practices. It is a useful reference for structuring oversight conversations. Read NIST’s Govern guidance.

A suggested board discussion

The questions below are practical prompts for a management briefing, rather than a certification checklist.

1. What decision are we being asked to make?

Distinguish permission to experiment from permission to expand. Ask management to state the proposed change, the intended benefit, and the alternatives considered in one paragraph.

2. Where will the system’s output matter?

Ask for a concrete workflow example. Who sees the output? Who might act on it? What happens if it is wrong? A demonstration can reveal consequences that a product description leaves unclear.

3. What evidence supports this recommendation?

Request the test conditions, unresolved issues, and limitations alongside positive results. A useful briefing makes clear which conclusions are supported and which remain assumptions.

4. Who can change or stop the deployment?

Name the business decision-maker and the operational contact. Ask what would trigger escalation, how quickly a change can be made, and who will explain that decision to affected teams.

5. What will we revisit at the next meeting?

Agree on a short follow-up: progress against the intended benefit, material problems, changes in use, and decisions still outstanding. Avoid adding measures simply because they are easy to collect.

Make the output usable

A practical one-page briefing can contain the decision requested, a workflow example, evidence reviewed, open questions, and the next review date. Keep supporting detail available for challenge.

The aim is to help leadership understand the choice before it, and the evidence that could change that choice.

Discuss your AI governance questions with StrategyAI Partners.

Back to Insights