A small company does not need a thick governance manual before it can manage AI responsibly. It does need a shared record of where AI is used, what could go wrong, who owns the risk and what evidence shows that controls work.
That record is an AI risk register.
The register can be a spreadsheet, database or ticket board. Its value comes from the decisions it supports, not the software that stores it. A useful entry connects one actual use case to one risk event, one accountable owner, a proportionate treatment plan and a date or event that forces another review.
This guide provides a lightweight template for small teams. It draws on the NIST AI Risk Management Framework’s Govern, Map, Measure and Manage functions, the NIST Generative AI Profile, OECD principles and security guidance. It is not a compliance certificate and does not replace legal, privacy, employment, safety or sector-specific advice.
What an AI risk register is
An AI risk register is a living list of risks associated with AI systems and AI-enabled business processes. It can cover tools your company builds, buys, configures or simply allows staff to use.
Each entry should describe a plausible event, not a broad topic. “Privacy” is a category. “A staff member pastes customer health information into a public chatbot that the vendor may retain” is a risk event. The second statement can be assigned, controlled and tested.
A register is also different from an AI inventory. The inventory answers what systems and use cases exist. The risk register answers what may happen, why it matters, how likely and serious it is, and what the organization will do. The two should link to each other so that a new system or material change automatically prompts risk review.
NIST describes its AI RMF as voluntary and intended to help organizations incorporate trustworthiness into the design, development, use and evaluation of AI. NIST also says its Playbook is not a universal checklist. That is useful guidance for a small business: borrow the actions that fit the use case, while preserving a clear record of why the chosen controls are proportionate.
When a small business needs a register
Start a register as soon as AI moves beyond private experimentation and touches company data, customers, employees, public claims or operational decisions.
Common triggers include:
- A generative AI assistant receives confidential business or personal information.
- AI-generated text, images or code are used in published work or products.
- A model recommends, ranks or screens people, such as applicants or customers.
- An agent can send messages, change records, create orders or call external tools.
- A vendor changes its model, data terms, hosting location or retention practices.
- An AI output could affect safety, legal rights, health, money or essential services.
- The business depends on one AI vendor for a time-sensitive process.
Do not wait for a model to be labeled “high risk” by a regulation. A modest customer-support workflow may still create expensive errors if it invents policy, exposes data or promises refunds without authority.
Use the REGISTER workflow
The UrleBird’s REGISTER workflow keeps the process small enough to use and rigorous enough to support decisions.
R — Record the system and use case
Name the tool, model or vendor and describe the exact task. “Marketing uses AI” is too vague. “The content team uses a hosted model to draft product descriptions from approved specification sheets” is usable.
E — Explain the context and affected parties
Document where the input comes from, who sees the output, whether a person reviews it and who could be affected. The same model may present low risk for brainstorming and high risk for screening job applicants.
G — Group the risk
Choose a primary category: accuracy, privacy, security, fairness, intellectual property, transparency, safety, continuity, misuse or third-party dependence. Tags help reporting, but the narrative risk event remains primary.
I — Identify the owner and evidence
Assign a business owner who can accept or change the process. A technical contact or vendor manager can support the entry, but “IT” should not become the owner of every business consequence. Link tests, approvals, contracts and monitoring records.
S — Score urgency
Estimate likelihood, impact and the gap in current controls. The score ranks attention; it does not prove safety or compliance.
T — Treat the risk
Select an action: avoid the use, reduce the risk, transfer part of it contractually, or accept the remaining exposure with recorded authority. Define a control, owner and due date.
E — Establish review triggers
Use calendar reviews plus event triggers. Reassess after a model update, a new data source, an incident, a vendor-policy change, a new user group or a move from human-assisted to autonomous action.
R — Retire or retain
Close entries only when the use case ends or the risk no longer exists. Preserve enough history to explain the decision and confirm that data, credentials, integrations and automated jobs were removed.
The 18-field AI risk register template
Use one row per distinct risk event. One use case may need several rows because privacy, accuracy and operational continuity have different causes and controls.
- Risk ID: a stable identifier such as AIR-024.
- System or vendor: the product, model and version when known.
- Use case: the specific business task.
- Lifecycle stage: idea, pilot, production, changed or retiring.
- Business owner: the person accountable for the process outcome.
- Technical or vendor contact: the person who can investigate or implement controls.
- Data classification: public, internal, confidential, sensitive personal or regulated.
- Affected people and processes: customers, staff, applicants, suppliers or operations.
- Risk event: the unwanted event in a cause-event-impact form.
- Cause or vulnerability: why the event could occur.
- Potential consequence: harm to people, operations, trust, contracts or legal obligations.
- Existing controls: current preventive, detective and corrective measures.
- Likelihood: a documented estimate from 1 to 5.
- Impact: a documented estimate from 1 to 5.
- Control gap: 1 for strong evidence, 2 for partial evidence, 3 for weak or absent evidence.
- Priority and automatic escalator: the calculated score plus any stop condition.
- Treatment plan: action, owner, due date and expected residual risk.
- Evidence, status and next review: test results, approval link, open or closed state, date and trigger.
Keep the definitions beside the register. A number is not repeatable if each reviewer uses a different meaning for “likely” or “major.”
A simple, transparent priority calculation
For internal triage, calculate:
Priority score = likelihood × impact × control gap
Likelihood and impact each range from 1 to 5. Control gap ranges from 1 to 3. The possible score is 1 to 75.
A small team can use these working bands:
- 1–10: monitor through normal ownership.
- 11–25: add or test a control and set a due date.
- 26–50: senior review before expansion; address promptly.
- 51–75: pause or sharply limit the use until accountable leadership approves an adequate treatment.
These bands are an internal prioritization aid, not a regulatory classification. Calibrate them against the company’s real tolerance and loss scenarios.
Do not allow multiplication to hide severe cases. Apply an automatic escalator when the use involves:
- Safety, health or an irreversible physical effect.
- Employment, eligibility, access or another consequential decision about a person.
- Sensitive personal or regulated data.
- Minors or other vulnerable groups.
- Autonomous payments, publication, deletion or external communication.
- A control that cannot be tested or a failure that cannot be detected promptly.
An escalated entry receives named senior review regardless of its numeric score. This prevents an uncertain low-likelihood estimate from neutralizing a potentially catastrophic impact.
Worked example 1: customer-support drafts
Use case: an AI assistant drafts answers from an approved help center; a support agent must review and send.
Risk event: outdated retrieval content causes the assistant to invent a refund entitlement, leading to inconsistent promises and customer disputes.
Existing controls might include a restricted knowledge base, human approval, links to cited policy sections and sampling of sent replies. The owner could score likelihood 3, impact 3 and control gap 2, producing 18.
The treatment is not “tell staff to be careful.” It could be: refresh the indexed policy weekly, block free-form answers when retrieval confidence is low, show the cited source to the agent and audit 30 random replies each month. Evidence belongs in the register.
If the company later allows the assistant to send messages without review, that material change triggers reassessment. The autonomy escalator applies even if the underlying model is unchanged.
Worked example 2: meeting transcription
Use case: a vendor records and summarizes internal client calls.
Risk event: confidential client information is retained longer than expected or used outside the company’s approved purpose.
The register should capture meeting scope, participants, data classification, recording notice, retention, deletion process, sub-processors and access controls. A contract alone is not complete evidence; test whether administrators can actually delete recordings and whether exports remain elsewhere.
A proportionate treatment may restrict the tool to approved meeting types, prohibit especially sensitive discussions, set automatic deletion and require host confirmation before recording. Privacy or legal review may be necessary depending on location, participants and data.
Worked example 3: marketing content
Use case: a team generates product copy and illustrations for review.
Risk event: generated material includes an unsupported product claim or content too similar to protected work, creating consumer, contract or intellectual-property exposure.
Controls can include approved source packs, claim-level verification, similarity checks, human editorial approval and a provenance record for each asset. Do not claim a tool makes content “copyright safe” unless the evidence and contract support that statement.
A low-risk brainstorming session may need only basic rules. Published claims need traceable sources and approval because the context—not the novelty of the model—drives impact.
Worked example 4: applicant ranking
Use case: a tool ranks job applicants.
Risk event: unsuitable data, proxy variables or an unvalidated model create unfair or unlawful screening outcomes.
This is a consequential decision. Apply the automatic escalator. Involve qualified employment, privacy and legal specialists before use; define what the tool may influence; test outcomes; preserve an appeal and human review path; and avoid using the score as the sole decision.
A generic template cannot determine the rules that apply in every jurisdiction. The register should record the applicable assessment, evidence and approval rather than assuming the software vendor has resolved the employer’s obligations.
Make evidence part of every control
“Human review” is not evidence by itself. Record who reviews, what they check, the time available, the rejection criteria and how the company measures misses.
Similarly, “vendor is secure” should become testable evidence: a completed assessment, relevant assurance report, contractual incident notice, sub-processor list, access configuration and an owner who reviews changes.
Useful evidence can include:
- Pre-deployment test cases and acceptance thresholds.
- A data-flow diagram and approved data classifications.
- Sampled-output error rates and reviewer overrides.
- Security test results and access logs.
- Vendor terms, assurance documents and change notices.
- Incident tickets, corrective actions and closure checks.
- Training records for people using or reviewing the system.
Evidence should be dated and scoped. A test on one model version or use case may not support a different one.
Set a review cadence that a small team can sustain
Review high-priority or fast-changing uses monthly. Review stable, lower-risk uses quarterly. Run a full inventory-to-register reconciliation at least twice a year, or more often if adoption changes quickly.
Event-driven review is more important than a calendar alone. Create a trigger for model or vendor changes, new integrations, new data, autonomy, new markets, incidents, material error trends and legal or contractual changes.
Track a small set of metrics:
- Percentage of production AI uses with an owner and current review.
- Percentage of high-priority treatments overdue.
- Control tests passed versus planned.
- Incidents and near misses by category.
- Human overrides or rejected outputs where meaningful.
- Time from material change to risk reassessment.
Do not optimize for zero recorded risks. An empty register can mean people are not reporting. Better signals are timely identification, evidence-backed treatment and fewer repeated failures.
A 30-day rollout
Week 1: discover
Collect AI tools from procurement, browser extensions, expense records, team interviews and existing technology inventories. Describe real use cases instead of product names alone.
Week 2: map
Create register entries for production and pilot uses. Start with concrete risk events involving data, external outputs, people and operational dependence. Assign owners.
Week 3: measure
Define the scoring scale, apply automatic escalators and gather evidence. Prioritize gaps where a system can act externally or where errors may materially affect people.
Week 4: manage
Approve treatments, pause uses that exceed tolerance, schedule reviews and publish a short intake rule for new AI tools. Report the top risks, overdue actions and decisions to leadership.
At day 30, the goal is not a perfect catalog. It is a working loop in which new use cases are captured, material changes cause review and owners can show whether controls perform as intended.
Common mistakes to avoid
Do not create one risk row for an entire vendor. A summarizer, coding assistant and applicant screener can have different inputs, users and consequences even if they share a model.
Do not copy a generic list without translating it into business events. “Bias, privacy, hallucination” does not tell an owner what to do.
Do not make the score the decision. Qualitative context and automatic escalators matter.
Do not close a risk because a policy exists. Test the control and attach the result.
Do not treat the register as legal compliance. Map it to applicable contracts, laws, standards and sector rules with qualified help.
Finally, do not hide uncertainty. If a vendor will not disclose retention, model changes or incident terms, record that missing information as a control gap.
The bottom line
A useful AI risk register is a decision system in miniature. It connects a real use case to a specific failure, consequence, owner, control, evidence and next review.
Start small, but make each field meaningful. The REGISTER workflow and 18-field template give a small business a practical foundation that can expand with its AI use. When the organization later adopts a formal framework or faces new obligations, it will already have the most valuable ingredients: traceable decisions, named ownership and evidence.
FAQ
What is the difference between an AI inventory and an AI risk register?
An inventory lists systems, vendors and use cases. A risk register records specific unwanted events, causes, impacts, controls, owners, scores and treatment plans. Link each risk entry to an inventory record.
Can a small business keep the register in a spreadsheet?
Yes. A well-controlled spreadsheet can work for a small team. Protect access, preserve change history, use stable IDs and link evidence. Move to a workflow tool only when ownership, approvals or reporting become difficult.
How often should an AI risk register be reviewed?
Use both calendar and event-driven reviews. Monthly review suits high-priority or rapidly changing uses; stable lower-risk uses may be reviewed quarterly. Reassess after model, data, vendor, autonomy, audience or regulatory changes and after incidents.
Does a low score mean an AI use is safe?
No. A score is a prioritization aid based on assumptions. Apply automatic escalation for safety, sensitive data, consequential decisions, vulnerable people and autonomous external actions, and have qualified reviewers assess applicable obligations.
Who should own an AI risk?
The owner should be accountable for the business process and able to change or stop it. Technical, security, privacy, legal and vendor specialists may support the owner, but risk should not default to IT merely because AI is technology.
