An AI onboarding process is something most organisations do not have, at least not in any consistent form. There may be a general procurement process for major software purchases, or an IT security review for new systems. Neither was built for today’s reality, where a capable AI tool can be adopted in minutes, costs nothing, and may never touch the IT infrastructure at all.
This gap is one of the biggest structural weaknesses in most organisations’ AI governance, and it is the gap shadow AI flows through. Closing it means building something rigorous enough to matter and fast enough to actually get used.
What an AI onboarding process needs to cover
A useful AI tool assessment does not need to cover everything. What it needs to do is focus on where the real risk sits, and produce a clear decision – approved, approved with restrictions, or not approved – with enough documentation to explain and revisit that decision later.
The supplier and data handling review matters most. What are the supplier’s terms on data retention? Does the tool keep prompts, for how long, and why? Are prompts or outputs used to train the model? Where is data processed and stored, and does that raise UK GDPR considerations, in line with the ICO’s guidance on AI and data protection? Does the supplier offer a data processing agreement, and is it adequate?
The data classification check asks one simple question: what categories of organisational data are likely to reach this tool in normal use, and is that acceptable given the supplier’s terms? For instance, a tool that keeps prompts indefinitely and trains on them is a very different proposition for drafting marketing copy than for handling customer support queries containing personal data.
Next comes the access and integration review, which covers what the tool can reach beyond what the user gives it directly. Browser extensions need particular attention here, since some request permissions covering every tab, saved credentials, clipboard contents, or browsing history. Those permissions need explicit review, not default acceptance.
Finally, the business purpose check asks whether the tool serves a real business need, and whether an approved alternative would already do the job. This is not gatekeeping – it is about making sure the governance effort of adding a new tool matches the benefit.
Building an onboarding process people will actually use
The design of the process matters as much as its content. A process that takes three weeks, needs a committee meeting, and delivers its verdict by email to the IT helpdesk will not get used. Staff will simply adopt the tool anyway and say nothing, which is the exact outcome the process was meant to prevent.
A proportionate process should be completable in two to five working days. It needs a clear owner – typically someone in IT security, risk, or a combined technology governance role – who is accountable for the decision, not just for coordinating it. Just as importantly, it should produce a written record of the decision and the reasoning, so the assessment can be revisited when supplier terms change or new information appears.
Lower-risk tools – those handling only public information, with no access to organisational systems, under standard terms – suit a lightweight fast-track. By contrast, higher-risk tools, such as those handling personal data, integrated into core systems, or with unusual terms, need a more thorough look. A tiered process that matches effort to risk works better than one process applied to everything.
The approved tool inventory
The output of onboarding is an entry in the approved tool inventory: not just a decision, but a record of what the tool was approved for, what restrictions apply, what data categories are acceptable, and when the approval needs reviewing.
This inventory is a living document. Staff need to be able to check quickly whether a tool is approved and under what conditions, and it needs periodic review to catch supplier terms that have changed, original approvals based on use cases that have since expanded, or tools that have fallen out of use and can be removed.
AI supplier terms change unusually often, sometimes with little notice. An approval that was sound when made can be inadequate six months later if the supplier has updated its data handling practices. For this reason, building a review trigger into each approval record – either date-based or linked to supplier change notifications – is a simple way to stop approvals quietly going stale.
What happens when staff bypass the onboarding process
No approval process catches every tool adoption. Some staff bypass it on purpose, some do not realise they needed to use it, and some use a tool in ways nobody anticipated when the process was designed.
The response should focus on improvement, not blame. If the process is being bypassed often, the likely cause is that it is too slow, too unclear, or too hard to find – process problems, not staff compliance problems, and worth fixing on their own terms.
When unapproved usage turns up, the priority is understanding what data has been involved and whether action is needed, then bringing the tool into the assessment process rather than simply banning it. After all, an organisation that meets every bypass with restriction creates an adversarial relationship with staff that makes governance harder, not easier. This is the same starting point covered in what should an AI acceptable use policy cover.
Black Chili’s AI Governance and Guardrails Design service includes an AI approval and onboarding process built around how your organisation actually operates.
If you are not sure what AI tools are in use inside your organisation, an AI Exposure Review gives you a clear, independent picture - what is being used, what data it touches, and where the real risks are.
