The role of an AI operating partner: scope, skills and governance

In most finance departments, private equity funds, family offices (structures that manage a family's wealth) and accounting firms, artificial intelligence experiments are multiplying. One team is testing a document summarisation tool, another a drafting assistant, a third a cash flow forecasting prototype. These trials often produce convincing demonstrations and sometimes local gains, whose measurement has yet to be established, but they remain isolated and almost never become part of lasting day-to-day operations. The question is therefore no longer whether a trial can be run. It is who decides what goes into production, who is accountable for it and how to verify over time that the tool is genuinely creating value.

This is the gap that the AI operating partner function seeks to fill. The term comes from the world of private equity, where an operating partner (literally, a partner focused on operations) is an experienced executive who supports a fund's teams in improving the companies held in its portfolio. Applied to artificial intelligence (AI), the function becomes a person, or a small team, responsible for connecting strategy, the business, data and technology, with an explicit objective: turning intended uses into decisions, controlled deployments and measured results. This role is not that of a developer, nor that of a consultant who hands over a report and then disappears, nor that of a committee that meets without ever reaching a decision.

This article describes the scope of this role, the skills it requires and the three possible modes of engagement: one-off, recurring or across a portfolio. It also details governance, that is, the set of rules that specify who decides, who controls and who is accountable. It covers use case owners (the business people who are accountable for each concrete application of AI), the AI steering committee (the body that settles priorities and decisions to go into production) and a responsibility matrix (a table that specifies who does the work, who is accountable and who is consulted). The article ends with the limits of the role, questions to ask before appointing someone and a printable checklist. Reading it will help you distinguish this role more clearly from neighbouring functions, assess whether your organisation needs one and draft an engagement letter that sets out responsibilities and the points still to be decided.

Why this role is becoming necessary#

Three gaps explain the difficulty. They are often addressed separately, even though they feed into one another.

Three gaps to close#

• The gap between the business and technology. Finance teams know how to describe a closing process, a bank reconciliation or the analysis of an investment case. They are less sure which steps can be automated, with what data and at what level of reliability. Conversely, the chief information officer (CIO), who is responsible for all of the company's IT tools, knows how to connect systems, but does not always see the purpose of a control built into the business process. No one then translates between the two languages.
• The gap between demonstration and production. A demonstration is convincing in a meeting. Regular use requires something else: defined access rights, sufficiently clean data, a verification procedure, user training, maintenance and a way of reverting to the previous process if the tool fails. Many trials, known as pilots (experiments limited to a narrow scope), stop at the threshold of going into production, that is, the move to real and regular use. This blockage stems less from a lack of talent than from the absence of anyone tasked with getting across that threshold.
• The accountability gap. When a summary produced by a language model (a program trained on very large quantities of text to produce plausible text) contains an error, who should spot it, who corrects it and who answers for it to senior management? Without a clear answer, uses spread in the shadows, with confidentiality and traceability risks that no one can assess.

A particular tension in private equity#

In a fund, portfolio companies (the businesses in which the fund has invested) do not all have the same level of digital maturity. One industrial company may have a well-structured management system, while another still works with shared spreadsheets and email exchanges. The fund wants consistency of method, but it cannot impose a single solution without taking into account the realities of each company and its own governance. The AI operating partner role sits precisely at this junction: it defines a common framework, then adapts how it is applied to each situation.

Defining the AI operating partner#

A borrowed term, a broader function#

In private equity, the operating partner is traditionally a professional who has held operational responsibilities, such as running sales, manufacturing or finance. They work with the executives of portfolio companies to improve their performance during the holding period, that is, the time during which the fund remains an investor. They are not always a shareholder, hence the word ‘partner’, which denotes a working collaboration rather than an equity stake.

Applied to AI, the function retains this stance: a perspective from outside the operational routine, a knowledge of performance levers and an ability to arbitrate. It adds enough technical competence to hold a meaningful dialogue with the teams that design or integrate the tools, as well as an understanding of data and regulatory issues.

A working definition#

The AI operating partner can be defined as the person responsible for moving uses of artificial intelligence from the idea stage to that of a managed capability. They identify opportunities, rank them, check that they rest on usable data, support their move into production and ensure that their effects are measured. They report to senior management or to the fund.

A large share of these uses relies on generative AI, that is, systems capable of producing text, tables or summaries from an instruction written in everyday language. This family does not, however, cover everything. Cash flow forecasting, anomaly detection in accounting entries and automatic document classification draw on different techniques, each with its own data and control requirements. A good operating partner does not confuse these families, because they do not call for the same safeguards.

The scope of the role#

The scope of an AI operating partner is defined by what they steer, what they influence and what they leave to others. The most common mistake is to entrust them with the entire subject, which turns the role into a one-stop shop, indispensable in appearance and fragile in practice. The following table proposes a division of responsibilities to be discussed before any appointment.

The four areas to cover#

• Selecting use cases. The role chooses where AI makes sense, avoiding both dispersion and projects that touch no indicator tracked by senior management. It is less a matter of collecting ideas than of concentrating effort on a few applications whose value is plausible and verifiable.
• Preparing the data. A use case is only as good as the data that feeds it. The role inventories the sources, spots inconsistencies in definitions (two departments that use ‘customer’ to mean different populations, for example) and flags the preliminary workstreams, which are often less spectacular but decisive.
• Governing risk. The role checks that each use has a control proportionate to its consequences, a record of decisions and a responsible person. It does not replace the legal functions, but ensures that their requirements are built into the project from the outset.
• Human adoption. A tool that is not adopted rarely creates measurable value. The role ensures that users understand what the tool does and does not do, that they know when to check it and that they have a channel for reporting a problem.

Value creation as the common thread#

Value creation refers to the lasting increase in what the organisation derives from its activity, once costs and risks have been taken into account. In a company, it shows up in growth, margins, investment capacity and financial strength. In a fund, it is also reflected in the value of the company at the time of its sale, because a buyer may be more willing to pay for an organisation that it can understand, steer and control.

For an AI operating partner, value creation is the criterion that links all decisions. An appealing tool that changes neither revenue, nor a margin, nor a risk, nor a decision probably creates no demonstrable value. The levers fall into four families.

• Revenue. AI can improve the preparation of commercial proposals, the personalisation of interactions with customers or the tracking of opportunities. The effect is measured by the proportion of proposals that result in an agreement, not by a general impression.
• Costs and margins. Reducing repetitive tasks, allocating team time more effectively and relying less on external services for standardised work can be sources of value worth examining as a priority. Measurement covers the time spent on tasks before and after the change, relative to the total cost.
• The quality of decisions. More numerous scenarios, better documented and prepared with less effort, can help senior management compare options it would not otherwise have had the time to examine. The effect can be real, but it remains indirect and is seen mainly in the quality of documented decisions.
• Risk. More systematic detection of anomalies, traceability of decisions and documented controls can reduce the likelihood of costly incidents. Their value is often invisible as long as nothing happens, which makes it difficult to measure and justifies an explicit method.

Measuring without inventing figures#

A serious article on this subject does not propose a benchmark value, because it would depend on each organisation. It does, however, propose a method, which must be applied before any launch.

• The starting point (baseline). Before launching a use case, the current process is described precisely: its steps, its participants, its known errors, its cycle time. Without this snapshot, any improvement remains an impression.
• The key performance indicator (KPI). A KPI is an indicator that sums up an objective. It must be chosen before deployment, linked to a value lever and accompanied by a written calculation rule, so that no one can redefine it after the fact.
• Attribution. It is necessary to distinguish what is due to the tool from what is due to another change, such as a reorganisation or a variation in activity. Comparison with a control group, that is, a comparable area that does not use the tool, remains the most rigorous method where it is possible.
• Total cost. It includes licences, design time, training, change management (supporting teams through the transformation, covered in more detail later), maintenance and human oversight. An omitted cost skews the reading of everything else.

The reference formula is simple. Net value equals measured benefits minus total cost, adjusted for the level of residual risk, that is, the risk that remains once controls are in place. It does not provide a ready-made result, but it requires each term to be named.

Responsibilities across the cycle#

The role is carried out according to a four-stage cycle: scoping, prioritisation, deployment and monitoring. These stages form a loop rather than a straight line, because the lessons drawn from monitoring feed into the next round of scoping. An organisation that has not institutionalised this loop ends up with projects that pile up without ever being evaluated.

Scoping#

Scoping consists of turning a wish or an idea into a precise problem, with clear boundaries. It involves three sequences.

• The diagnosis. It lists the processes that could be improved, the data available and the tools already in use. It also identifies shadow uses, that is, tools used by employees without approval. These reveal a real need, but also a confidentiality risk, which must be dealt with without penalising those who use them.
• Framing the problem. Good scoping describes the problem before the solution. ‘We want to use a language model’ is not a problem. ‘Investment committee notes are not linked to the decisions taken, which makes it difficult to track the assumptions’ is one.
• The use case sheet. A use case is a concrete application of AI to an identified problem. The sheet is the single document that describes it: problem, user, data required, level of risk, success criterion and designated owner. Without a sheet, there is no use case, only an intention.

Prioritisation#

Prioritisation consists of ranking use cases to decide which will be launched, which will be postponed and which will be abandoned. It most often relies on a matrix that plots potential impact against feasibility. Impact is the expected effect on the value levers, estimated qualitatively and openly acknowledged as such. Feasibility aggregates several factors: data quality, technical complexity, the teams' appetite and exposure to regulatory risk.

A third axis must be incorporated: the risk specific to the use case. An application that influences a sensitive decision, such as a credit assessment or the screening of job applications, requires additional precautions, reinforced human oversight and sometimes outright exclusion. Prioritising also means saying no, and that is often the hardest decision to get accepted.

Deployment#

Deployment takes a use case from the sheet to real use. It follows a predictable sequence, and each stage can be refused if its conditions are not met.

• The supervised pilot. This is a trial on a limited scope, with exit criteria written in advance: what will allow the work to continue, be corrected or be stopped.
• Validation by the owner. The use case owner accepts the results and the rules of use. Without this validation, the move into production has no sponsor within management.
• Going into production. This refers to the move to regular use, integrated into processes, with identified access rights and maintenance.
• The fallback procedure. It describes how to revert to the previous process if the tool is unavailable or if its outputs become doubtful. A procedure that has never been tested does not really exist.
• Human oversight. It enables a competent person to understand an output, check it and correct it before it has consequences. This principle often recurs in regulatory approaches, a point to be verified with a lawyer.

Monitoring#

Monitoring is the most neglected stage. Once the tool is in place, it must be checked that it keeps its promises over time. To do this, the role organises four types of control: usage indicators (who uses the tool and for what), the quality of outputs measured on a controlled sample, incident tracking and drift detection. Drift refers to the phenomenon whereby data or uses change and performance deteriorates without anyone noticing, because the original conditions have changed. Monitoring leads to an explicit decision to continue, adjust or stop. Stopping a use case is a governance decision like any other, and it must be treated as such.

The skills required#

The profile sought rarely combines all these skills in a single person. They must therefore be present in the role, either in the individual or within a team around them. Five skills appear indispensable.

Finance expertise#

An AI operating partner must understand the logic of an income statement, a balance sheet, a cash flow plan or a business plan (the company's forward-looking plan). They must know what an investment decision involves, how an accounting close and reporting (the management reports sent to senior management) are carried out, and what the constraints of an investment committee are. This knowledge is not meant for doing the finance team's work, but for proposing use cases that touch indicators that are genuinely tracked. Without it, the role produces appealing ideas that the finance department never adopts, because it does not recognise them as useful.

Understanding data#

It is not a matter of knowing how to program, but of knowing where data comes from, who produces it, how it is defined and what its limits are. The notion of reference data is central: it is the single authoritative source for a given piece of information, such as the customer master file or the list of charts of accounts. Data quality breaks down into several criteria: completeness (nothing is missing), accuracy, consistency across systems and freshness. A model reflects the data that fed it, and it reproduces its biases. Knowing how to read these limits avoids entrusting a machine with decisions based on fragile foundations.

Change management#

Change management refers to the set of methods that support people through a transformation: explaining the reasons, involving users early, training, recognising legitimate resistance, then measuring adoption. The most common pitfall is a tool that works technically, but that no one uses, or that is used in a way that was not intended. An AI operating partner must understand that a large part of the value is determined by working habits, not by the code.

A sense of risk#

A sense of risk consists of distinguishing an acceptable risk from an unacceptable one, then designing the appropriate controls. It involves anticipating the plausible errors of a language model, which can produce a fluent but false answer, known as a hallucination (an output that seems correct without being so). It also means thinking through failure scenarios: what happens if the tool is unavailable, if its answers change without warning, if confidential data is entered by mistake? Finally, it involves knowing when a human must validate and when automation is acceptable.

The ability to decide#

An AI operating partner must propose reasoned options, recommend clearly and get decisions made. A role that never leads to a decision becomes a meeting facilitator. This ability also means accepting unpopular decisions: abandoning a project dear to a team, postponing a promising use case for lack of reliable data, or rejecting a solution that does not meet control requirements. Decision-making is the point at which all the other skills come together.

The three modes of engagement#

The AI operating partner can work in three ways, which meet different needs and levels of maturity. The choice must be explicit, because each mode creates distinct expectations, timelines and risks.

The one-off mode#

The one-off mode is based on a defined engagement, set in advance around a precise purpose: an initial diagnosis, scoping a first use case, reviewing a project in difficulty, preparing a technology investment decision. It produces an identifiable deliverable, such as a diagnosis, a roadmap or a set of recommendations. It suits an organisation that wants an honest assessment of where it stands before committing. Its main weakness is that the deliverable often goes nowhere if no one internally takes it forward. An internal owner who will take over the work must therefore be planned for from the outset.

The recurring mode#

The recurring mode provides for a regular presence, at a pace set in advance. The individual leads the steering committee, settles priorities, tracks indicators and supports use case owners. It suits organisations engaged in several simultaneous workstreams, which need continuity of method. The point to watch is dependence on one person: if all the knowledge rests on a single individual, their departure weakens the whole. The recurring mode must therefore include a handover plan, with documents, sheet templates and written procedures.

The portfolio mode#

The portfolio mode concerns a fund or group that wishes to work across several entities. It aims to standardise the selection and governance method, share lessons learnt, prevent each company from buying comparable tools on scattered terms, and ensure consistency of data and compliance rules. It has three limits. The first is excessive standardisation that ignores the business specificities of each company. The second is a tension between the fund's logic and the operational autonomy of each executive. The third is a risk of conflict of interest if the individual is linked to a solution provider, which requires transparency about such links.

Use case owner and AI steering committee#

Two bodies structure day-to-day governance. One is individual, the other collective. They must remain distinct, because confusing accountability for a single use with decisions on the portfolio as a whole leads to deadlock.

The use case owner#

The use case owner is the business person who is accountable for the success of an AI application, its value and its operational risks. They are not necessarily the most technical person; they are the one who knows the process and who will bear its consequences. Their responsibilities include:

• Defining the need. They describe the problem to be solved, the situations in which the tool will be used and those in which it must not be.
• Validating the data. They confirm that the data used matches the reality of the business and flag any discrepancies they observe.
• Accepting the rules of use. They approve the way the tool is used, the checks to be carried out and the situations that require human review.
• Measuring the effect. They contribute to defining the indicators and check that these reflect what they observe day to day.
• The local decision. They propose to the committee the extension, adjustment or discontinuation of the use case.
• Leading change within their team. They drive adoption among their colleagues, with the support of the operating partner role.

Two failures are common. A use case without an owner becomes an orphan: no one answers for errors, and the project runs out of steam as soon as its initiator changes jobs. Conversely, an owner who is too technical, with no connection to the business, produces tools that appear high-performing but are little used, because they do not match actual practice.

The AI steering committee#

The AI steering committee is the collective body that decides on priorities, moves into production and the usage policy. It generally brings together senior management or one of its representatives, the finance department, the IT department, the head of data (sometimes called the data director or Chief Data Officer, the person who guarantees the definition and quality of the company's data), a legal or compliance function, a representative of the business concerned and the operating partner, who chairs its proceedings. It meets regularly, on a schedule set in advance, so that it does not depend on the urgency of the moment.

Its typical agenda has four items:

• Pending decisions. These concern use cases to be launched, validated or stopped, each accompanied by a reasoned recommendation.
• Indicators. The committee reviews usage, output quality and incidents, without getting lost in technical detail.
• New risks. A regulatory change, an incident or a change in the data may justify an exceptional decision.
• Usage policy. The committee regularly revises the usage charter, that is, the written rules that specify which tools are authorised, what data may be entered, which checks are mandatory and who may launch a new use.

The committee must be a decision-making body, not merely an information forum. If decisions are made elsewhere, it becomes a place for presentations, and governance shifts into informal conversations that escape all control.

Governance and the responsibility matrix#

A responsibility matrix indicates, for each activity, who carries out the work, who is accountable for the result, who must be consulted and who must be informed. The most common form is the RACI matrix, named after its four letters:

• R (Responsible): carries out. The person who does the work. An activity may have several people carrying it out.
• A (Accountable): answers and decides. The person who has the final say and who answers for the outcome. An activity must have only one A, otherwise no one is truly accountable.
• C (Consulted): consulted. The person whose opinion is sought before the decision, without deciding themselves.
• I (Informed): informed. The person who must know about the decision, without taking part in it.

The following table is a starting template, to be adapted to each organisation. It illustrates the division most often found in a mid-sized company or fund. The legal function does not appear as a column for readability; it must nevertheless be consulted on all rows relating to compliance and usage policy.

Several reading rules make this table useful rather than decorative:

• Only one A per row. When two people consider themselves accountable, the decision is made by default or is reopened at every meeting. The table must designate a single final accountable party, even if several people carry out the work.
• No R without an A. An activity entrusted to someone without anyone being accountable for it generally ends up not being done, or being done without control.
• Do not overload the committee. The committee settles cross-cutting questions. Owners are accountable for their own area. If the committee ends up as the A on every row, it becomes a bottleneck, and the matrix must be reviewed.

The role alongside other players#

The most common confusion is to believe that the AI operating partner replaces one of the existing players. This is not the case: the role sits between them, and its effectiveness depends on the quality of these relationships.

The consultant#

The consultant brings a method, expertise and an outside perspective, generally embodied in a deliverable: a study, a diagnosis, a decision framework. Their engagement is defined in advance and ends on a date set by the contract. The operating partner stands out through a presence over time: they lead decisions, follow the move into production and measure the effects. The consultant is assessed on the deliverable, the operating partner on the ability of the use case to hold up over time. A consultant may, however, be brought in for one-off support, under the responsibility of the operating partner, on a specific technical or legal issue.

The chief information officer (CIO)#

The CIO is responsible for the entire information system: infrastructure, applications, security and technical projects. Decisions on architecture, hosting, integration and access security fall to the CIO. The operating partner does not stand in for the CIO, but ensures that technical choices serve a defined use case and that security constraints are anticipated. The tension is real, because the CIO has limited resources and a portfolio of competing projects. The operating partner must therefore place these requests within a shared prioritisation, rather than handle them one by one as emergencies arise.

The head of data#

The head of data governs definitions, reference data, access rights, data quality and compliance with the General Data Protection Regulation (GDPR), the European framework governing the collection and processing of personal data. They are an indispensable partner. They do not, however, necessarily own the value of the uses or their adoption by the business. The operating partner relies on the head of data to make the data reliable, while the head of data relies on the operating partner to know which workstreams are genuinely priorities.

The head of innovation#

The head of innovation explores technologies, tests prototypes, scans the horizon and mobilises teams around new ideas. Their horizon is longer and their logic is that of exploration, which accepts many trials that lead nowhere. The risk is that the prototype remains a prototype: many ideas tested, few moves into production. The operating partner brings the discussion back to decision, measurement and real use. The two functions are complementary: innovation feeds the list of possible use cases, and the operating partner turns it into decisions.

Why the distinction matters#

Confusing these roles produces specific effects, which governance must anticipate:

• Combining roles. Entrusting the same person with both the technical decision and the decisions on uses removes a cross-check. The choice of a tool may then serve the solution at hand rather than the need expressed.
• Confusion. A consultant who holds the role takes the knowledge with them at the end of the engagement, leaving the organisation without an operational memory.
• The vacuum. If each of the players above thinks the subject is being handled by someone else, no one holds the full loop, and uses multiply without monitoring.

Questions to ask before appointing someone#

Before appointing an AI operating partner, whether internal or external, the following questions make it possible to check that the mandate is clear. Each is accompanied by the reason for asking it.

• What value creation problem must the mandate solve? A mandate phrased as ‘prepare our AI strategy’ is too broad to be evaluated. A mandate that cites a value lever and a specific decision is far less so.
• What decision must it inform? A useful mandate ends with an identifiable decision, such as launching a first use case, stopping a project or approving a usage policy.
• Which use cases already exist, and who owns them? You need to know the actual inventory, including shadow uses, to avoid starting from scratch or duplicating initiatives.
• What data is genuinely accessible, and on what terms? Data that is theoretically available, but impossible to extract or to use lawfully, does not count in the calculation.
• Who decides in the event of disagreement between the business and the technical side? Without an answer, every disagreement becomes a deadlock. The mandate must designate the body that decides.
• What degree of independence from software vendors and service providers? A person who derives a financial benefit from a solution cannot arbitrate objectively between several options. This transparency must be put in writing.
• How will results be measured, and who validates the measurement? If the appointing party and the appointee do not agree on the method, no assessment will be accepted.
• What is the plan for handing over the method? The question of the exit is often forgotten. A role that leaves behind no documents, no bodies and no internal skills takes away with it what made it valuable.
• What confidentiality, retention and traceability obligations apply, and who checks them with a lawyer? The rules on personal data and on AI may impose requirements that should be identified from the outset, and their interpretation must be checked with a lawyer.

The limits of the role#

A well-defined role is first and foremost a well-bounded role. The following limits must be known to management and to the individual alike, otherwise expectations quickly exceed what can be done.

• It does not replace the decision. The operating partner informs, recommends and organises the decision-making process. The decision remains that of the executive, the committee or the fund, which bears responsibility for it.
• It does not promise results. The value of a use case depends on the quality of the data, adoption by the teams, the competitive context and the quality of the initial scoping. A serious practitioner describes methods and criteria, not effects guaranteed in advance.
• It does not make up for a fragmented information system. When data is scattered across unconnected tools, the role can reveal the extent of the problem, but cannot resolve it alone. This workstream falls to the IT department and to overall strategy.
• It is not a legal function. It identifies points requiring attention, but the interpretation of regulatory obligations must be checked with a lawyer, particularly for uses that affect decisions concerning individuals.
• It must not become a bottleneck. If all decisions go through it, it slows down the organisation it is meant to support. Its task is also to transfer the method to owners capable of applying it.
• It depends on access to how processes really work. Without direct observation of day-to-day work, its recommendations remain theoretical and risk overlooking the exceptions that make a business complex.
• It must contend with the limits of models. A language model can produce a fluent but false answer, known as a hallucination. It can also reproduce biases, that is, systematic tendencies present in the data, or respond differently depending on how an instruction is worded. The role organises verification; it does not eliminate the need for it.

The regulatory framework: four principles to put into practice#

The European regulation on artificial intelligence, commonly known as the EU AI Act, organises uses of AI according to a risk-based approach. Without going into the detail of the obligations, which must be checked with a lawyer, four principles guide the governance of the role.

• The risk-based approach. The regulation distinguishes, subject to confirmation by a lawyer, levels of risk ranging from unacceptable to minimal. The more a use can weigh on a person's rights or on an important decision, the stronger the control requirements. The first task of an operating partner is therefore to classify each use case according to this level.
• Transparency. Under rules to be confirmed by a lawyer, people must be informed when they are interacting with an AI system, and uses must be documented: purpose, data, known limitations. Under rules to be confirmed by a lawyer, this requirement may also apply to documents produced with the help of AI when their readers might take them for human work.
• Human oversight. A competent person must be able to understand a system's outputs, check them and correct them. Oversight is not a formal review: it requires the reviewer to have the information and the time needed to exercise real judgement.
• Traceability. It must be possible to reconstruct what happened: tool versions, data used, instructions, outputs and decisions taken on the basis of those outputs. An organisation that records nothing can neither correct its errors nor respond to a request for an inspection.

Glossary#

• Operating partner: an experienced executive who supports the teams of a fund or a company in improving their performance. In this article, the person responsible for uses of AI over time.
• Value creation: the lasting increase in what the organisation derives from its activity, after taking costs and risks into account.
• Portfolio company: a company in which a private equity fund has invested and whose performance it monitors.
• Holding period: the time during which the fund remains an investor in a company, before selling it.
• Change management: the set of methods that support people through a transformation, from explanation to training and measuring adoption.
• Use case owner: the business person who is accountable for the success, value and operational risks of an AI application.
• AI steering committee: the collective body that decides on priorities, moves into production and the usage policy.
• Usage charter: written rules that specify the authorised tools, the data that may be entered, the mandatory controls and the conditions for launching a new use.
• RACI matrix: a table that divides responsibilities between carrying out the work (R), being accountable and deciding (A), being consulted (C) and being informed (I).
• Chief information officer (CIO): the person responsible for all IT tools, infrastructure, security and technical projects.
• Head of data: the person who guarantees the definition, quality, reference data and compliance of the company's data.
• Head of innovation: the person who explores technologies, tests prototypes and keeps watch on emerging uses.
• Generative AI: a family of systems capable of producing text, tables or summaries from an instruction in everyday language.
• Language model: a program trained on very large quantities of text to produce plausible text in response to an instruction.
• Hallucination: an output from a model that seems correct and well phrased, but contains false information.
• Drift: the gradual deterioration of a system's performance when data or uses change without the monitoring arrangements detecting it.
• Reference data: the single authoritative source for a given piece of information, such as the customer master file.
• Starting point (baseline): a precise description of a process before a tool is introduced, which serves as a point of comparison.
• Key performance indicator (KPI): an indicator that sums up an objective, chosen before deployment and accompanied by a written calculation rule.
• Control group: a comparable area that does not use the tool, in order to isolate its effect.
• Pilot: a supervised trial on a limited scope, intended to check feasibility and value before a wider roll-out.
• Going into production: the move from a trial to regular use, integrated into processes, with access rights, maintenance and a fallback procedure.
• Human oversight: the principle whereby a competent person can understand, check and correct a system's outputs.
• Traceability: the ability to reconstruct the data, versions, instructions, outputs and decisions associated with a use.
• Shadow use: a tool used by employees without the organisation's approval.
• Residual risk: the risk that remains once controls have been put in place.
• GDPR: the General Data Protection Regulation, which governs the collection and processing of personal data in the European Union.
• EU AI Act: the European regulation that governs uses of artificial intelligence by level of risk, to be checked with a lawyer.

Printable checklist#

• The problem to be solved is framed in terms of value creation, without starting from a technology.
• A specific decision is expected at the end of the engagement.
• The list of existing use cases, including shadow uses, has been drawn up.
• Each use case has a sheet with a designated owner.
• The data required is identified, access to it is confirmed and its quality is assessed.
• The risk level of each use is classified according to the risk-based approach.
• A starting point (baseline) is described before any launch.
• A key indicator is chosen, with its written calculation rule.
• The total cost is recorded, including training and human oversight.
• Human oversight is planned for each output that weighs on a decision.
• A fallback procedure has been drafted and tested.
• The AI steering committee is designated, with a schedule set in advance.
• The responsibility matrix has only one final accountable party per activity.
• The usage charter specifies the authorised tools and the data that must not be entered.
• Confidentiality and traceability obligations have been checked with a lawyer.
• Any links with software vendors or service providers have been declared.
• A plan for handing over the method is in place.
• A follow-up review is scheduled, with a clear criterion for continuing, adjusting or stopping.

Frequently asked questions#

Does an AI operating partner need to come from finance?#

Not necessarily, but they must understand its logic. Someone with an IT background can succeed if they surround themselves with strong business partners and acquire a genuine understanding of financial decisions. The reverse is also true: a finance professional must be willing to understand the constraints of data. What matters is the ability to translate between the two worlds.

How does this differ from a consultant who presents a study?#

The consultant delivers an analysis and a plan, and then the engagement ends. The operating partner stays in the loop: they follow the move into production, lead the decisions and check the effects. A consultant may, however, contribute on a one-off basis within a set-up steered by an operating partner.

Can this role be given to an internal employee?#

Yes, provided they have genuinely dedicated time, a written mandate and authority recognised by the committee. A role added on top of a main function, without time or legitimacy, mainly produces intentions. An internal choice can offer better continuity, but it exposes the person to conflicts with the teams whose work they must arbitrate.

How can the role be kept from becoming a bottleneck?#

By transferring the method. The use case sheet, the prioritisation grid, the dashboard template and the usage charter must be written, shared and applied by the owners. Thresholds must also be set beyond which a decision is taken locally, without being escalated to the committee.

Does the role need to be full time?#

It depends on the size of the organisation or portfolio and on the number of use cases under way. A one-off or recurring mode may be enough for an organisation that is just starting out. A fund with several companies engaged in simultaneous workstreams may justify a more sustained presence. The workload must be estimated before the decision, on the basis of the list of tasks, not on intuition.

Conclusion#

The AI operating partner function meets a concrete need: linking uses of artificial intelligence to decisions, responsibilities and measurable effects. Its scope covers scoping, prioritisation, deployment and monitoring, and it draws on skills in finance, data, change management, risk management and decision-making. It operates in three modes, one-off, recurring or across a portfolio, which must be chosen according to the organisation's maturity.

Its strength is also its limit. The role only makes sense if it remains bounded: it informs decisions without replacing them, it organises verification without claiming to eliminate error, and it passes on its method rather than keeping it to itself. A clear responsibility matrix, a steering committee that genuinely makes decisions and clearly identified use case owners are favourable conditions for this role to produce value. Before appointing someone, the questions presented here make it possible to check that these conditions exist, or to know where to begin.