Requirements · Enterprise AI tools
What an enterprise AI deployment needs in place before launch
Last updated 25 October 2026 · 3 sources listed · Reading time about 3 minutes
Short answer
Minimum conditions include an approved-use policy, a register of tools and use cases with owners, risk tiering, data classification rules, vendor due diligence, access and logging controls, human review expectations for consequential outputs, training, and an incident process. Legal duties differ by jurisdiction and sector, so confirm applicable rules with counsel and regulators.
Who this is for: A risk, compliance or security leader setting the minimum conditions a company-wide AI tool must meet before going live.
What to evaluate
Approved-use policy
Staff need plain rules about what data and tasks are acceptable.
How to check: Publish a short policy with concrete examples and a route to ask questions.
Register of use cases
You cannot manage risk you cannot see.
How to check: Keep an inventory listing purpose, owner, data used, vendor, risk tier and review date.
Risk tiering
Uses affecting people's rights or safety need stronger controls than drafting internal notes.
How to check: Define tiers and required controls for each, informed by applicable regulation.
Vendor due diligence
Providers process your data and shape behaviour.
How to check: Collect security attestations, data terms, subprocessor lists and incident commitments.
Human oversight rules
For consequential decisions, a person must be able to review and override.
How to check: Document who reviews what, with what information and authority.
Monitoring and incidents
Performance and misuse change over time.
How to check: Define metrics, sampling review and a response process for harmful or incorrect outputs.
Regulatory mapping
Rules on automated decisions, transparency and data protection differ by place.
How to check: Identify applicable regimes, for example in the European Union, and have counsel confirm obligations.
Comparison
| Tier | Example use | Typical controls |
|---|---|---|
| Minimal | Drafting internal summaries from non-sensitive material | Policy awareness, approved tool only |
| Limited | Customer-facing chat with disclosure | Transparency notice, content testing, escalation to a person |
| High | Screening applicants or assessing eligibility | Impact assessment, documented oversight, bias testing, record keeping, legal review |
| Prohibited or restricted | Uses barred by law or by company policy | Do not deploy; seek legal advice on boundaries |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 7 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Approved-use policy | |||
| Register of use cases | |||
| Risk tiering | |||
| Vendor due diligence | |||
| Human oversight rules | |||
| Monitoring and incidents | |||
| Regulatory mapping | |||
| Total (max 21) | 0 | 0 | 0 |
Questions to ask before you commit
- Which laws and sector rules apply to each use case in the places we operate?
- Who owns each use case and is accountable for outcomes?
- What data classes are allowed in which tools?
- Which vendors have passed due diligence and when is it repeated?
- How will we log and retain interactions, consistent with privacy rules?
- How do we test for harmful or biased outputs before and after launch?
- What is the process for reporting and handling incidents?
- How will staff be trained and how will we confirm understanding?
Typical trade-offs
Strict centralised approval versus risk-tiered self-service
- Upside
- Maximum control for critical uses.
- Downside
- Slows low-risk innovation; tiering concentrates review where it matters.
Detailed logging of prompts versus privacy minimisation
- Upside
- Supports investigations and audit.
- Downside
- Creates sensitive records and employee privacy concerns.
Adopting a formal management standard versus lightweight internal rules
- Upside
- External recognition and structure.
- Downside
- Overhead that may be disproportionate for small deployments.
Common mistakes
- Writing a policy nobody reads. Keep it short and use examples drawn from daily work.
- Counting only vendor-provided tools. Include features embedded in existing software.
- Ignoring employee privacy when monitoring AI use. Consult privacy and employee representatives.
- Treating compliance as one-off. Schedule reviews as tools and rules change.
Related questions
Do we need an AI-specific law review?
Yes for most larger deployments. Some jurisdictions have rules specific to automated decision making, transparency or high-risk systems, and data protection, consumer, employment and sector laws also apply. The specifics vary by country and industry and are subject to change, so involve legal counsel and consult the relevant regulator's published guidance rather than relying on summaries.
What is an AI management system standard?
It is a framework describing how an organisation sets policy, assigns roles, assesses risk, controls operations and improves over time for its AI activities. Certification, where offered, signals that a process exists, not that every output is correct. Smaller organisations can borrow its structure without pursuing certification.
How should we handle employees using unapproved tools?
Find out why: usually the approved option is missing a capability or is too slow. Offer a clear exception process, communicate rules and consequences, and provide an approved alternative that actually helps. Technical blocks help but are incomplete; culture and speed of approval matter as much.
What records support an audit?
The use-case register, risk assessments, vendor due diligence files, policy and training records, testing results, change logs and incident reports. Make sure records show decisions and their reasons, with dates and owners. Store them in a location with appropriate retention and access control.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- European Commission — European Commission, retrieved 27 October 2026
- EU Artificial Intelligence Act — Future of Life Institute, retrieved 27 October 2026
- AI Risk Management Framework — National Institute of Standards and Technology, retrieved 27 October 2026
Related guides
How to choose · Enterprise AI tools
How to choose an enterprise AI platform for company-wide use
Select on governance fit and integration depth before model capability. Verify identity and permission inheritance, data residency and retention, admin visibility into usage, evaluation and guardrail tooling, connector breadth into your systems of record, support for multiple model choices, and a commercial model that stays predictable as adoption spreads beyond the first enthusiastic teams.
Comparison · Enterprise AI tools
Build versus buy for enterprise AI capabilities
Buy where the capability is common and vendors can ship, support and secure it better than you can. Build where the workflow, data or user experience is a source of advantage or where packaged tools cannot meet control needs. Most firms end with a mix, so the key decision is a rule for which category each request belongs to.
Problems & fixes · Enterprise AI tools
Why enterprise AI rollouts stall and what to fix
Rollouts typically stall for organisational reasons: unclear use cases, weak permissions that make security block expansion, poor answer quality on internal content, absent training, and no measurement of value. Diagnose which of these applies, fix content and access foundations first, concentrate on a few workflows per function, and measure outcomes rather than logins.
Requirements · AI coding tools
What an engineering policy for AI coding tools should cover
A workable policy names approved tools and plans, forbids pasting secrets or customer data, sets repository eligibility, requires normal review and testing for all code regardless of origin, defines licence and provenance handling, covers agentic tool permissions, and assigns ownership for monitoring and updates. Keep it short enough that developers actually read it.
Problems & fixes · AI risk and governance
Shadow AI: staff using unapproved tools and what to do about it
Shadow AI arises when approved options are slow, limited or unknown. Prohibition alone seldom works. Combine discovery, a clear policy with examples, an approved alternative that meets real needs, a quick exception route, technical guardrails on sensitive data and training that explains reasons. Treat discovery as information about unmet needs rather than only a disciplinary matter.
Requirements · AI risk and governance
Requirements for using AI in decisions about people
Tools that influence decisions about people face the strictest expectations. Typical requirements include a defined lawful purpose, documented impact assessment, testing for discriminatory effects, transparency to affected people, meaningful human oversight with authority to override, routes to contest outcomes, record keeping, and vendor evidence. Laws differ by jurisdiction, so obtain legal advice and consult regulator guidance before use.
Requirements · AI agents
Requirements before giving an AI agent access to company systems
Before granting access, you need a defined task and owner, dedicated low-privilege credentials, a data classification of everything reachable, approval rules, logging with retention, a tested stop procedure, and agreement on who answers for outcomes. Without these, the agent inherits the access of whoever set it up, and nobody can reconstruct what it did.
All Enterprise AI tools guides · All Artificial intelligence