NIST AI Risk Management Framework
Used as a structure for identifying, measuring and managing AI risk across the lifecycle.
Responsible AI and Governance
Responsible AI must be built into the solution
Responsibility is a design activity, not a paragraph added at the end. Accountability, provenance, privacy, permissions, evaluation and observability are specified alongside the functional requirements and delivered with them.
Control architecture
How a controlled AI system is arranged
The sequence below is the arrangement we design towards. Each stage constrains the next, and the final stage feeds evidence back into the system.
Approved need to monitored improvementSix controlled stages
- 01Approved organisational needA defined task with an owner and agreed boundaries
- 02Controlled AI systemBounded scope, documented behaviour, restricted autonomy
- 03Approved data and toolsPermission-aware sources and least-privilege tools
- 04Evaluation and safeguardsPass criteria, guardrails, limits and failure handling
- 05Human-reviewed actionA person confirms consequential outcomes
- 06Monitoring and improvementLogging, review, incident handling and change control
Signal path between stagesStage active
EvaluationLearningImprovement
Seven practice areas
What responsible implementation involves in practice
01Human accountability and oversight
Every AI-supported process has a named person who remains responsible for the outcome. Systems are designed so that responsibility is exercisable rather than nominal.
- A named owner for each AI-supported workflow
- Professional oversight where the decision affects people, money, safety or reputation
- Review points placed where a person can still change the outcome
- Clear authority to restrict, pause or withdraw a system
- Documented escalation routes for uncertain or contested cases
- Workforce responsibility set out in guidance and training
02Data, evidence and privacy
Solutions are built on approved information with traceable provenance, and the minimum personal data the task genuinely requires.
- Provenance recorded for the documents and data in scope
- Permission-aware retrieval so users see only what they may see
- Data minimisation and redaction where full detail is unnecessary
- Secure use of organisational information, with residency decisions taken before build
- Defined retention for inputs, outputs and logs
- Removal process for superseded or withdrawn sources
03Agent permissions and tool restrictions
Autonomy is granted deliberately and narrowly. An agent receives only the tools, scopes and limits its task requires.
- Least-privilege tool and API permissions
- Explicit allow lists rather than open access
- Approval checkpoints before consequential actions
- Cost, time, volume and authority limits
- Tested failure and rollback behaviour
- Separation between test and production credentials
04Model, system and failure-mode evaluation
Evaluation is designed before build so the decision to release rests on evidence rather than impression.
- Representative evaluation sets, including difficult and unacceptable cases
- Agreed pass criteria and regression checks on every change
- Failure-mode analysis for the workflow, not only the model
- Bias and limitation awareness documented in plain language
- System-level testing across retrieval, tools, interface and process
- Honest reporting of what the system cannot do
05Observability, logging and audit
Behaviour that cannot be observed cannot be governed. Logging and tracing are treated as part of the solution.
- Structured logging of inputs, outputs, tool calls and decisions
- Tracing across multi-step and agentic runs
- Audit trails suitable for internal review
- Alerting on error rates, drift and unusual activity
- Access control and minimisation applied to logs themselves
- Review dashboards for the people accountable
06Security, misuse and deployment boundaries
AI features expand the attack surface. Security work considers the model, the data path, the tools and the people using them.
- Prompt-injection and untrusted-content handling
- Secret management and scoped service accounts
- Dependency and supply-chain awareness
- Defined deployment boundaries and prohibited uses
- Incident-response outline with named responsibilities
- Change management for models, prompts, tools and data sources
07Continuous review and change management
A system that was appropriate at release can become inappropriate as data, models, regulation and practice change.
- Scheduled review of samples, incidents and performance
- Re-evaluation after model, prompt or data changes
- Workforce guidance kept current as tools change
- Documented decisions when scope is widened
- A defined route to retire a system
- Learning fed back into process, data and training
Reference points
Informed by recognised guidance
Our approach may be informed by published frameworks and security guidance, adapted to the size, sector and risk profile of the organisation.
NIST Generative AI Profile
Referenced for risks and controls specific to generative systems.
OWASP guidance for LLM applications
Referenced for application-level risks including prompt injection, insecure output handling and excessive agency.
Privacy and information-security principles
Applied through minimisation, access control, retention limits and secure handling of organisational information.
What we do not claim. Referencing published guidance is not certification. SSTech Advisory does not hold or imply formal certification or accreditation, does not provide legal advice, does not guarantee compliance with any regulation and does not represent regulatory approval. Where a formal legal or regulatory position is required, it should be obtained from a qualified adviser.
Next step
Design the safeguards with the system, not after it.
If you are preparing to adopt generative or agentic AI, we can review the intended use, define proportionate controls and set out the evaluation and oversight the workflow requires.