How to Build an AI Adoption Team: Defining Roles for IT, Legal, and DX Using a RACI Framework

Make the core team a small base for promotion, technology and decision-making

The core team is the small group at the centre of driving AI adoption. Much depends on the size of the organisation, but in the early stages, as an illustrative figure, starting with three to five people tends to be easy to run.

Adoption lead

Often sits within the DX function, corporate planning, or a department charged with company-wide change; owns the purpose of AI adoption, the target areas, the priorities and reporting to management.

Technology and security lead

Typically the IT or information-security function. Handles tool selection, account management, permissions, log management, and checking whether integration with existing systems is feasible.

Decision-making and consensus lead

Provides the link to senior management and department heads, and confirms the budget, the scope, the risk appetite and the timing of any company-wide rollout.

Placing these three roles in the core team means you can handle “what we want to achieve”, “what conditions are needed to use it safely” and “how far we take it as an organisation” in one and the same room.

Bring the extended team’s specialist perspective in when it is needed

The extended team need not sit in on every meeting. These are the people you consult and ask to review depending on the question at hand.

Legal

Checks contracts, personal data, copyright and consistency with internal regulations. They particularly need to be involved early where documents go outside the company, where contracts are concerned, or in work involving personal or confidential information.

HR

Responsible for training, internal communication and developing skills by job type. Since AI adoption rarely translates into organisation-wide results if only a knowledgeable few use it, the design of the training matters a great deal.

Frontline representative

The role of judging which use cases genuinely work in real day-to-day work. They check whether the measures the AI adoption team has dreamt up are actually usable on the ground, and whether the burden on the frontline is not too great.

As needed, you might also fold communications, brand, audit, customer success and sales planning into the extended team.

Separate the place where you decide small from the place where you check broadly

A common misstep in AI adoption structures is to summon every stakeholder to the same meeting. The discussion broadens, but decisions struggle to move forward.

Have the core team check progress and take decisions weekly or fortnightly. Have the extended team review monthly, or by topic. Splitting things this way makes it easier to balance the pace of adoption against the checking of risk.

By way of illustration, here is what early operation might look like.

• Core team meeting: 30 minutes, fortnightly
• Extended review meeting: 60 minutes, once a month
• Report to management: once a quarter
• Frontline interviews: once a month per PoC department

These are not actual figures but a starting point for designing the structure. Adjust them to your organisation’s size, the number of departments involved, and the sensitivity of the information being handled.

The role of the DX and corporate-planning functions

The DX and corporate-planning functions own the job of defining the purpose and priorities of AI adoption.

When introducing AI becomes an end in itself, the frontline is left unclear about “what we are using it for”. The first task is to be clear about which business problems you want to solve.

Take, for example, questions of this kind.

• We want to cut the time spent writing up minutes after meetings
• We want to make internal query handling more efficient
• We want to speed up first drafts of proposals
• We want to lighten the load of producing training content
• We want to make internal knowledge easier to search

The DX function sorts these adoption themes out and decides the scope of the PoC (proof of concept — an exercise that tests practicality and issues on a small scale). It then tallies usage and results, feeding that into the decision on the next step.

The role of the IT and information-security functions

The IT function plays the role of supporting the foundations of AI adoption.

Its main areas are tool selection, account management, permissions, security, log management and integration with existing systems. The more widely you spread AI use across the frontline, the more it matters who can access which information.

The items to check are along these lines.

• The flow for adding and removing users
• Changing permissions for leavers and transfers
• The criteria for granting administrator rights
• Whether external integrations are permitted
• Requirements for log capture and auditing
• Restrictions on use in highly confidential work

To make AI adoption run smoothly, it is important to set up an environment the frontline can use with confidence first.

On tool selection, there are several options — Microsoft 365, Google Workspace, various generative AI services, internal knowledge-search tools, and so on. With Kanata, you can organise users, data and functions into units of space, project, app and library, and manage members and permissions per project. Where you want to separate information by department or purpose, you can consider this structure alongside your permissions design.

The role of the legal function

The legal function plays the role of sorting out what is and is not permissible in AI use.

Particularly important is the handling of input information. Public information, general internal information, customer information, personal data, undisclosed financial information and contract information cannot all be treated alike.

The UK Information Commissioner’s Office sets out, in its guidance on AI and data protection, that personal data must be handled appropriately when AI is in use. It is also sensible, in practice, to set up your operation so that AI output bearing on law, regulation or contracts is checked by your in-house legal team or by experts.

The questions the legal function should be involved in are as follows.

• Defining what information must not be entered
• Handling personal and sensitive information
• Conditions for handling contracts and customer materials
• Copyright, citation and secondary use of AI output
• Review criteria where AI is used in materials going outside the company
• Consistency with usage regulations and internal guidelines

If legal gets involved too late, you may find yourself rewriting the rules after the PoC. From the early stages of AI adoption, it is important to settle at least the minimum prohibitions and the criteria for seeking advice.

The role of the HR function

The HR function plays the role of making sure AI adoption does not remain the preserve of a handful of people.

Introduce an AI tool, and it will not take hold if staff do not know how to use it. And when understanding varies from one user to the next, so too will the quality of output and the awareness of risk.

The areas HR should own are along these lines.

• Foundational training for all staff
• Adoption training for managers
• Use-case training by job type
• Communicating the usage guidelines
• Onboarding for new hires and transfers
• An approach to assessing and developing AI skills

Training content might take several forms — video, e-learning, in-house study sessions, on-demand materials, and so on. With Kanata, you might combine AI chat, AI summarisation and e-learning, and run an arrangement that creates and distributes materials starting from video. Producing the training content is not, however, enough on its own. You need a flow in which people try it in real work after the session, pick up the questions that arise, and update the rules.

The role of the frontline representative

The frontline representative plays the role of connecting AI adoption to real work.

Measures thought up by the adoption team or the IT function alone inevitably lean towards a management-side view. But it is frontline staff who actually use the AI.

What the frontline representative should check is points of this kind.

• Is that use case genuinely high-frequency?
• Does using AI not, in fact, create more work?
• Is the burden of checking the output realistic?
• Does it suit the words and formats used on the ground?
• Are there not too many exceptions?
• If it works, does it look like it could be rolled out more widely?

The frontline representative is not merely a user but a tester for the AI adoption team. Bringing them in early makes it less likely you will be left with a purely theoretical structure on paper.

An illustrative RACI for AI adoption

The following is an illustrative example for when you design an AI adoption structure. These are not actual figures; adjust them as a starting point for an internal proposal.

Draw up this table and relationships come into view — for instance, “DX produces the first draft of the usage guidelines, and legal carries ultimate accountability”, or “HR is accountable for training, but the content is settled in consultation with DX and the frontline representative”.

What it is better not to over-prescribe with RACI

On the other hand, prescribe RACI in too much detail and the operation becomes heavy-going.

There is no need to push everyday prompt tweaks, an individual’s tidying of work notes, or small adoption ideas within a department all the way down into RACI. Put everything through an approval process and the frontline’s trial and error grinds to a halt.

What RACI should make clear are the areas where the risk or scope of impact is large.

• Work handling confidential information
• Documents that go outside the company
• Output bearing on contracts and legal matters
• Guidelines rolled out company-wide
• Policies bearing on training and assessment
• The design of tools and permissions

Leave the small, everyday improvements to the frontline, and use RACI to make responsibility clear for the high-impact judgements. Striking that balance is what matters.

Decide the purpose and the core team

The first thing to settle is the purpose of AI adoption.

“Use AI across the company” is far too broad. Begin by narrowing down which business problems you are targeting.

By way of illustration, themes of this kind.

• Make writing up minutes after meetings more efficient
• Reduce the volume of internal queries
• Speed up first drafts of sales materials
• Lighten the load of producing training content
• Make internal knowledge easier to search

Once the purpose is decided, appoint the adoption lead, the IT lead, and the person responsible for decision-making and building consensus. At this stage there is no need to gather every stakeholder across the company. Begin by forming a small core team and sorting out the questions.

Decide the usage guidelines and prohibitions

Next, draw up the minimum usage guidelines.

What matters here is not to try to write a perfect set of regulations from the outset. Begin by putting in writing the points where staff are most likely to hesitate.

• Information that may be entered
• Information that must not be entered
• How to mask personal data
• Review criteria before anything goes outside the company
• Areas where AI output must not be used as-is
• Where to turn when a judgement is unclear

Bring legal and IT in at this stage, and being clear about “prohibited” and “consult first” makes the later rollout easier to advance.

Trial with the use cases narrowed to three

In the early stages of AI adoption, it is important not to widen the use cases too far. Begin by choosing work that is high-frequency, where the benefit is easy to feel, and where the risk is easy to manage.

By way of illustration, here are three.

1. Summarising minutes. Working from a meeting recording or notes, you sort out the decisions, the to-dos and the key points of the discussion.
2. Internal FAQ. You make it possible to answer routine queries to HR, general affairs and IT on the basis of regulations and manuals.
3. First drafts of proposals and reports. You reduce the burden of writing from a blank page so that people can concentrate on checking and editing the content.

You can choose your tool from existing groupware, general-purpose generative AI, knowledge-management systems, AI adoption-support platforms and the like. With Kanata, you can consider an arrangement that separates AI chat, AI summarisation and e-learning by project, and manages prompts and training data in a library.

Measure the results and judge the next phase

Once the PoC is over, check the usage record and the frontline’s reaction.

The metrics to watch are not simply the number of times it was used. Check from considerations of this kind.

• Number of users
• Continued-use rate
• Time spent on the target work
• The burden of reviewing output
• Number of queries
• Frontline satisfaction
• Whether any risks or near-misses occurred
• Departments it looks like it could be rolled out to

By way of illustration, suppose you ran a three-month trial across five departments with fifty people; you might design things so that, each month, you check the “number of uses”, the “time spent on the target work” and the “proportion that needed correction at review”.

Here too, it is important not to write figures you have no actual basis for as results. In internal proposal materials, set out “illustrative examples”, “target values” and “actual values” separately.

Leaving it all to IT

Introducing an AI tool is an area IT readily takes the lead on. Press ahead with IT alone, however, and although the security and account design may be sound, it can end up not fitting the frontline’s business needs.

The way to avoid this is to bring the DX function and a frontline representative in from the tool-selection stage. Be clear about what you want to achieve, then sort out the functions and constraints you need.

Pressing ahead with the DX function alone

Conversely, press ahead with the DX function alone and, although adoption themes emerge, information management and legal checks can end up trailing behind.

In particular, where there is any prospect of handling customer information, contract information or personal data, a late legal or IT check can leave you with no choice but to halt the operation after the PoC.

The way to avoid this is to settle, at the early stage, even just the three of “prohibited information”, “consult-first information” and “review before anything goes outside the company”.

Leaving the legal check until last

Leave the legal check until last and you readily end up in a state of “the frontline has already started using it, but under the rules there is a problem”.

The legal function is not there to put a stop to AI adoption. Its role is to set the conditions for spreading it safely.

Consult them early, and rather than prohibiting everything from the outset, sort out together “under which conditions it may be used”.

Not bringing HR and training on board

AI adoption will not spread while it remains something only the knowledgeable use. In particular, where the skill gap among frontline staff is wide, the usage rules and the way prompts are written vary from person to person.

The way to avoid this is to design, together with HR, separate foundational, job-type and manager training. There is no need to teach advanced use from the outset. It is more realistic to begin with the information that must not be entered, how to check output, and the work templates in frequent use.

Having no frontline representative

With no frontline representative on the adoption team, the organisation chart may be in good order, yet the measures tend not to fit real work.

Produce a template for summarising minutes, for instance, and if it does not suit the actual meeting body it will go unused. Build an internal FAQ, and if the frontline cannot search it in the words they use, it will not take hold.

The way to avoid this is to bring one or two frontline representatives in from the PoC departments and verify the templates and operating rules together.