B7. Roles and Responsibilities for AI in the Enterprise
Roles and responsibilities for AI in the enterprise: RACI matrix, role profiles, and decision rights.
AI only has a lasting impact when it is clear who is responsible for what, across the entire lifecycle from strategy and idea intake through development and operations to optimization and decommissioning.
What this chapter delivers: roles, decision rights, and the associated templates (RACI matrix, role profiles) bundled in one place. Chapter B6 sets the organizational form; here the roles within it become concrete.
Principles for role distribution
A role has a clear goal, measurable outcomes, and defined decisions.
Tasks are distributed along the lifecycle: intake, design, development, review, approval, operations, monitoring, improvement, decommissioning.
Responsibilities are separated: whoever develops does not review their own work; whoever approves is independent.
Central guardrails, decentralized delivery: central teams secure standards and building blocks, business units deliver products and impact.
Every role has a backup, handovers, and documented ways of working.
Roles along the lifecycle
The following role map shows all of the chapter’s roles at a glance, grouped into the four sections that follow in detail. Important: the map describes functions, not positions; how roles are bundled depending on company size is covered in the scaling section at the end of the chapter.
Each role is described with five fields: what the role is, why it is needed, its core tasks, how it differs from neighboring roles, and who typically fills it. Anyone introducing a role in practice transfers these details into the role profile further below. Technical terms are explained in parentheses at first mention.
Strategic and early phase
Executive AI sponsor
Field
Description
What the role is
A member of the executive board or management team who acts as patron for the entire AI program. It is an additional mandate on top of the existing board role, not a dedicated position and no operational involvement: the person secures top-level backing and decides in case of conflict, but does not work on individual initiatives.
Why it is needed
AI initiatives compete across business units for budget and people. Without an advocate at the top level, they lose this contest against the day-to-day business, which always feels more urgent in the short term.
Core tasks
Represents the AI portfolio (the entirety of all AI initiatives) at board level, approves priority and budget, resolves conflicting goals between units, and sets the portfolio boundaries, including which fields of application the company deliberately does not pursue.
Differentiation
Does not develop the AI strategy (that is the Chief AI Officer’s job) and does not steer the running program (AI program lead). Decides where those levels can no longer resolve matters, for example in budget or priority conflicts.
Typical assignment
CIO, CDO, or CFO on the board; in smaller companies, the managing directors themselves.
Chief AI Officer / CIO with AI mandate
Field
Description
What the role is
The leadership role with subject-matter accountability for the AI strategy, comparable to a division head who sets the course for their topic. In many companies not a separate title but a mandate (an explicit remit) that the CIO or CDO takes on in addition.
Why it is needed
Someone has to translate business goals into a consistent AI strategy and enforce it across unit boundaries. Without this bracket, isolated solutions emerge that run in different directions in every unit.
Core tasks
Translates business goals into the AI strategy, owns the principles, the target architecture (the technical target picture), the roadmap, and the steering model, and reports to the executive AI sponsor.
Differentiation
Sets the direction but does not run the program’s day-to-day business (AI program lead) and does not make budget decisions at board level (executive AI sponsor).
Typical assignment
CIO or CDO with an AI mandate; in large companies a dedicated Chief AI Officer position.
AI program lead
Field
Description
What the role is
The operational steering role for the AI program: day to day, it holds all running AI initiatives together, comparable to a program manager in classic transformation programs. While the Chief AI Officer sets the what and where, this role ensures the orderly how and when.
Why it is needed
Otherwise individual AI initiatives run uncoordinated side by side, and nobody has the overview of status, mutual dependencies, and risks.
Core tasks
Collects new ideas through an orderly entry process (intake), organizes their evaluation and prioritization, tracks status and risks across units, and prepares the decisions of the Portfolio Board.
Differentiation
Prepares portfolio decisions but does not make them (that is the Portfolio Board’s job). Does not own individual products (AI product owner).
Typical assignment
Experienced program or project manager, often based in the AI competence center.
AI Portfolio Board
Field
Description
What the role is
A decision-making body, that is, a fixed group of named people from business units, IT, data, risk, and finance that decides on the AI initiatives together. Not an individual role but a standing group that meets regularly.
Why it is needed
Decisions on intake and sequencing of initiatives affect several units at once. A shared body prevents the loudest or most powerful unit from prevailing instead of the most sensible initiative.
Core tasks
Decides on intake, prioritization, and termination of initiatives, aligns the portfolio with strategy and budget, and meets at a fixed cadence (see the portfolio review in chapter D4).
Differentiation
Decides on the portfolio as a whole, not on the content of individual products (AI product owner) and not on the strategy itself (Chief AI Officer).
Typical assignment
Named representatives of the units involved; typically chaired by the Chief AI Officer or the AI program lead.
Enterprise architecture lead
Field
Description
What the role is
The existing IT architecture function, extended by AI questions. Enterprise architecture is the overall blueprint of the IT landscape: it defines how systems, data, and interfaces are meant to fit together, so that not every project builds its own incompatible solution.
Why it is needed
AI solutions built past this target picture create integration and security problems and can hardly be scaled later.
Core tasks
Reviews new initiatives for fit with the target architecture, data platform, integration, and security, approves technical interfaces, and maintains reference architectures (proven design blueprints, see chapter B5).
Differentiation
Sets the technical guardrails but does not build (that is done by development teams and platform engineering). Security approvals rest with the AI security lead.
Typical assignment
Head of enterprise architecture or a lead architect with AI experience.
AI FinOps lead
Field
Description
What the role is
The role for the financial steering of the AI landscape. FinOps (short for financial operations) is the practice of making running cloud and AI costs continuously visible and steering them together with the business units, instead of discovering them only later on the invoice. Here applied to AI-typical costs such as token costs (billing per processed text unit) and training costs.
Why it is needed
AI costs are usage-driven and hard to predict: every request costs something, and the sum grows with usage. Without continuous cost transparency, budgets derail unnoticed (see chapter D2).
Core tasks
Creates cost transparency per use case, defines unit metrics (e.g., cost per request), plans budgets and forecasts, and establishes showback or chargeback: showback shows each unit the costs it caused, chargeback actually bills them to it.
Differentiation
Steers costs but does not decide on portfolio prioritization (Portfolio Board) or the service levels of individual applications (AI service owner).
Typical assignment
Controller or cloud FinOps professional with an AI focus; in smaller companies a part-time duty of IT controlling.
Process and change management
Field
Description
What the role is
A role or team for the organizational side of AI adoption: changed workflows, changed roles, and the accompanying communication. Change management means the structured guiding of change so that those affected come along instead of blocking.
Why it is needed
AI initiatives only hold up when, alongside the technology, acceptance and process changes are resolved (see chapter B11).
Core tasks
Analyzes the impact on workflows and roles, plans communication and training measures, accompanies rollouts in the business units, and measures acceptance.
Differentiation
Owns the change of the organization. Building AI skills rests with the training and enablement team, the individual product with the AI product owner.
Typical assignment
Change management from HR or organizational development, closely linked with the AI competence center.
Data and governance
Data owner per domain
Field
Description
What the role is
A business-side manager with ownership responsibility for the data holdings of a domain (a subject area such as customer data or production data). A business role, not an IT role: it is about the content-level authority over the data, not its technical operation.
Why it is needed
Without a named owner it remains unclear who may grant access and demand quality. Data requests pile up and projects get delayed, because nobody is allowed to decide.
Core tasks
Decides on access and approvals, sets quality goals, defines the purpose limitation (what the data may and may not be used for), and represents the domain toward compliance and data protection.
Differentiation
Decides but does not implement (that is the data steward). Does not review legal bases (data protection officer).
Typical assignment
A manager of the business unit that owns the data. Cannot be delegated to IT, because the business assessment does not sit there.
Data steward per domain
Field
Description
What the role is
The operational data role that implements the data owner’s requirements in day-to-day work. Steward means caretaker: where the data owner decides, the steward executes and keeps the data in order.
Why it is needed
Quality rules and data catalogs do not maintain themselves. Without a steward, the metadata (the descriptive information about the data, such as origin and meaning) goes stale and data quality erodes gradually.
Core tasks
Implements the quality rules, maintains the data catalog, metadata, and classification (the rating by sensitivity), handles access and quality requests, and reports problems to the data owner.
Differentiation
Implements but does not decide on approvals and purpose limitation (that stays with the data owner).
Typical assignment
An experienced domain professional with an affinity for data, often part-time alongside the actual line role.
Data protection officer
Field
Description
What the role is
A legally required role under the GDPR, here extended by AI-specific reviews. It watches over the lawful processing of personal data.
Why it is needed
AI systems often process personal data in new contexts. Without early involvement, fines and costly rework shortly before go-live loom.
Core tasks
Reviews legal bases, consent, retention periods, and data-subject rights, accompanies data protection impact assessments (the mandatory risk review for sensitive processing, DPIA for short), and advises product owners and data owners early in the initiative.
Differentiation
Reviews data protection, not the entire regulatory landscape (compliance and legal) and not ethical questions beyond the law (Responsible AI).
Typical assignment
The company’s appointed data protection officer, internal or external.
Responsible AI officer / ethics board
Field
Description
What the role is
A role or body for the responsible design of AI beyond legal minimum requirements. Responsible AI asks not only what is allowed, but what is defensible.
Why it is needed
The law only defines the floor. Questions of fairness, transparency, and human oversight decide the trust of customers and the workforce (see chapter B10).
Core tasks
Creates guidelines on fairness, explainability, and transparency, requires a bias assessment before approvals (the check whether a model systematically disadvantages certain groups), defines usage boundaries, and escalates critical cases.
Differentiation
Assesses ethical acceptability, not legal permissibility (compliance, data protection) and not statistical model risks (model risk management).
Typical assignment
A single named role in smaller organizations, an interdisciplinary body in larger ones.
Compliance and legal
Field
Description
What the role is
The existing compliance and legal function, extended by AI regulation. Compliance means adherence to laws and requirements and the audit-proof evidence of it.
Why it is needed
The EU AI Act, GDPR, and industry rules require evidence and approvals. Violations endanger licenses, budget, and reputation (see chapter B8).
Core tasks
Assesses initiatives from a regulatory perspective (including the risk class under the EU AI Act), owns the contracts with vendors, maintains the audit evidence (the audit-proof records of controls), and clarifies liability questions.
Differentiation
Reviews legal conformity overall. Data protection in the narrow sense rests with the data protection officer, technical protection measures with the AI security lead.
Typical assignment
Compliance and legal departments, supplemented by external law firms with an AI focus where needed.
Development and platform
AI product owner per use case
Field
Description
What the role is
The business-side product ownership for a single AI use case. The term comes from agile development: the product owner is the one person who decides what gets built and in what order, and who is accountable for the benefit toward the business.
Why it is needed
Without a business owner the development team optimizes past the actual need, and nobody measures whether the solution achieves its business goal.
Core tasks
Formulates vision and goals, translates business goals into requirements, prioritizes the backlog (the ordered list of open tasks), signs off on results, and measures impact against the baseline (the value measured beforehand without AI).
Differentiation
Owns the product until go-live, after which the AI service owner takes over operations. Does not decide on data approvals (data owner).
Typical assignment
A person from the business unit that receives the benefit. Not an IT role.
Business analyst
Field
Description
What the role is
An analysis role at the interface between the business unit and the development team. It translates between both worlds: business workflows into precise requirements and technical options back into the business context.
Why it is needed
AI solutions need precisely described processes and measurable starting values. Without a baseline (the measured state before the introduction), the benefit cannot be proven later (see chapter D1).
Core tasks
Analyzes and documents the current processes, defines metrics and collects baselines, supports the product owner with requirements and the business case.
Differentiation
Analyzes processes and metrics but does not develop models (data scientist) and does not prioritize the backlog (AI product owner).
Typical assignment
Business analyst from the business unit or an IT-adjacent analysis team.
Data engineer
Field
Description
What the role is
An engineering role for data delivery. It builds the path from the source systems to the prepared data used to train and operate models, comparable to building and running the pipes before anyone turns on the tap.
Why it is needed
In practice, a large share of effort in AI projects lies in data sourcing and preparation. Poor data paths (pipelines) are the most common technical cause of delays.
Core tasks
Sources and models data, builds and operates pipelines (the automated processing paths), ensures data quality and traceability of origin (lineage, the gapless data trail), and delivers data for training and inference (the productive model operation).
Differentiation
Delivers the data but does not develop models (data scientist) and does not build model pipelines (machine learning engineer).
Typical assignment
Software engineer with a data focus, usually in the platform or data team.
Machine learning engineer
Field
Description
What the role is
An engineering role that makes models production-ready. It connects data science with software engineering and operations, in short MLOps or LLMOps: the practice of putting models into operation reliably, repeatably, and under monitoring, the way DevOps does for classic software.
Why it is needed
A model in a notebook (a data scientist’s experimentation environment) is not yet a product. Without reproducible pipelines, tests, and versioning, every solution gets stuck at the pilot stage (see chapter C3).
Core tasks
Builds the training and inference pipelines, ensures reproducibility, versioning, and automated tests, and deploys models and keeps them up to date.
Differentiation
Industrializes the models but does not design them (data scientist) and does not operate the underlying platform (platform engineering).
Typical assignment
Software engineer with ML experience; often bundled with data engineering in one team.
Data scientist
Field
Description
What the role is
The methods role for model development, from choosing the approach to evaluating the results. It answers which approach best solves a problem and how good the solution really is.
Why it is needed
The choice of methods, features, and evaluation criteria determines the quality and robustness of the solution. That requires statistical and methodological expertise.
Core tasks
Develops and compares models, chooses the method, evaluates results against baselines, documents in model cards (the standardized profiles of a model), and supports interpretation in the business context.
Differentiation
Develops the models but is responsible neither for their production operation (machine learning engineer, AI service owner) nor for data delivery (data engineer).
Typical assignment
Data scientist with a statistics or ML background; for GenAI solutions increasingly with prompt and evaluation expertise.
Platform engineering
Field
Description
What the role is
The team that provides and operates the shared data and AI platform on which all use cases build. It delivers the shared basic equipment so that not every project procures it anew.
Why it is needed
Without a shared platform, every project builds its own infrastructure. Costs, security, and operations then become unmanageable.
Core tasks
Provides environments and compute capacity, operates observability (the ongoing insight into system state via metrics, logs, and traces) and automation, and delivers reusable building blocks such as model access and vector databases (special stores that make text searchable by meaning and power the RAG search); supports teams during onboarding.
Differentiation
Operates the platform, not the individual applications on it (AI service owner). Does not develop models.
Typical assignment
The IT platform or infrastructure team, extended by AI components.
AI security lead
Field
Description
What the role is
A security role focused on AI-specific threats, usually as an extension of the existing information security function.
Why it is needed
AI introduces attack surfaces that classic IT security does not cover: prompt injection (instructions smuggled into the input that hijack the model), data exfiltration through models, and data poisoning (the deliberate poisoning of the training data), see chapter B9.
Core tasks
Creates threat models for AI systems, defines protection measures and access controls, grants security approvals, and maintains audit trails and response plans.
Differentiation
Owns technical security. Regulatory approvals rest with compliance and legal, ethical usage boundaries with Responsible AI.
Typical assignment
Security team or CISO organization (information-security leadership) with AI upskilling.
Operations and continuous development
AI service owner
Field
Description
What the role is
The accountable role for a production AI application over its entire operating period. It is the permanent owner in operations, where the project role of the product owner ends.
Why it is needed
After go-live, project logic ends. Without a service owner, the application is orphaned: costs and quality spiral out of control because nobody feels permanently responsible.
Core tasks
Accountable for availability, service levels (the promised performance values such as response time and reachability), cost, security, and quality in operation, commissions further development, and decides on decommissioning together with the AI product owner.
Differentiation
Takes over from the AI product owner after go-live. Technical monitoring is carried out by site reliability engineering.
Typical assignment
IT service management or the operations organization; in smaller companies combined with the AI product owner in one person.
Site reliability engineering
Field
Description
What the role is
The operations role for the stability and performance of production AI systems. Site reliability engineering (SRE) is a way of working that originated at Google, running IT operations like an engineering discipline: reliability (availability and response times) is set as a measurable target, and recurring operational work is replaced by automation instead of chasing incidents by hand indefinitely.
Why it is needed
AI systems fail differently than classic software, for example through gradual quality degradation (drift, the drifting of model quality as reality shifts) or sudden load spikes at inference. That requires specialized, continuous monitoring.
Core tasks
Builds monitoring and alerting, defines recovery procedures for the failure case, analyzes incidents systematically, and optimizes stability and response times.
Differentiation
Secures technical operations but is not accountable for service levels and costs toward the business unit (that is the AI service owner).
Typical assignment
The IT operations or SRE team.
Support tiers
Field
Description
What the role is
A tiered support organization for user questions and technical incidents, built in several tiers (levels) with increasing depth of expertise.
Why it is needed
Without a clear support path, all questions land directly with the development team and block its further development.
Core tasks
Tier 1 answers simple user questions, tier 2 handles technical incidents, tier 3 performs root-cause analysis together with development.
Differentiation
Handles incidents and questions. Systematic quality problems are escalated by support to the AI service owner and model risk management.
Typical assignment
The existing support organization, tier 1 with basic AI training.
Model risk management
Field
Description
What the role is
An independent review body for model risks. In regulated industries (banks, insurers) it is established and expected by supervisors. Independent means here: not reporting to the team that built the model.
Why it is needed
Whoever develops does not review their own work. An independent body spots weaknesses that the team’s own members miss under pressure to succeed.
Core tasks
Reviews models before approval and in ongoing operation (accuracy, drift, fairness, usage boundaries), demands countermeasures, and can require the withdrawal of a model from production.
Differentiation
Reviews the statistical and subject-matter model risks. Legal review rests with compliance and legal, ethical assessment with Responsible AI, technical security with the AI security lead.
Typical assignment
An independent risk function; in smaller companies at least one knowledgeable person not involved in the initiative.
Training and enablement team
Field
Description
What the role is
The team for building AI skills across the entire organization. Enablement means putting employees in a position to use AI tools safely and sensibly.
Why it is needed
AI literacy (basic AI competence) is mandatory (Art. 4 EU AI Act) and a prerequisite for acceptance. Without systematic enablement, tools remain unused or are used incorrectly (see chapter B11).
Core tasks
Develops and delivers training, maintains guides and self-learning offerings, builds communities of practice (professional exchange groups across unit boundaries), and measures learning progress.
Differentiation
Imparts the skills. The organizational change itself is steered by process and change management.
Typical assignment
People development together with the AI competence center.
Decision rights across the AI lifecycle
Decisions are made where responsibility and expertise reside: strategic direction in bodies (Portfolio Board, executive management), operational decisions with the product, data, and service owner. Security and compliance approvals are always independent of development and operations. The table is illustrative and should be adapted per organization.
Role
Typical decision rights
Collaboration
Executive AI sponsor
Approve priority and budget, resolve conflicting goals
Exactly one A (Accountable) per task; R, C, and I as needed. R = Responsible (executes), A = Accountable (decides and owns), C = Consulted (asked for input), I = Informed (kept informed).
The table is deliberately an excerpt: it contains the six roles involved in practically every use case and the tasks with the greatest potential for conflict. Depending on the initiative, further roles from the role map are added as columns (such as the machine learning engineer, Responsible AI, or the data protection officer) and further tasks as rows.
Task
Product owner
Data owner
Data scientist
Security
Compliance
Service owner
Data approval
C
A
C
C
C
I
Model development
A
I
R
C
I
I
Security approval
C
I
I
A
C
I
Regulatory approval
C
C
I
C
A
I
Go-live
A
I
C
C
C
R
Operations / monitoring
I
I
C
C
I
A
Template: role profile
The role profile is filled out once per role and stored centrally. It prevents responsibility from existing only verbally, and it is what makes backups and handovers possible in the first place: a new person can take over the role from the profile without relying on oral tradition.
Field
Content
Role
Name
Goal
What does the role stand for?
Core tasks
3 to 5 main tasks
Decision rights
What can the role decide alone?
Interfaces
Key collaboration partners
Deliverables
Which artifacts does the role deliver in a binding way? Examples: the model card from the data scientist, the cost report from the FinOps lead, the approval evidence from compliance. The artifacts per role are picked up in the following section.
Metrics
2 to 3 success indicators (suggestions in the metrics-per-role section)
Backup
Who covers in case of absence?
Work artifacts, cadences, and bodies
Roles remain paper if they deliver nothing tangible and never meet. This section therefore defines what results the roles produce (artifacts, see the deliverables field in the role profile) and in what rhythm they come together (cadences and bodies). Every role delivers binding artifacts: role profile, RACI per use case, model and data cards, evaluation and approval evidence, security and data-protection documents, service targets, and cost reports. This is anchored in fixed cadences: weekly status meetings per product, biweekly architecture and security review, monthly portfolio review, quarterly review of target architecture and guidelines, annual effectiveness review of governance.
Segregation of duties
The principles at the start of the chapter demand separated responsibilities; this section makes the separation concrete. Segregation of duties means certain roles must never coincide in one person or team, because conflicts of interest arise otherwise, for instance when a team approves its own model while being measured by its success. Clean task separation avoids these conflicts and satisfies compliance requirements at the same time.
Development and approval are separated; an independent body reviews quality and risk.
Operations and audit are separated; reviews are conducted neutrally.
Data approvals are controlled by data owners, not by developers themselves.
Production access is strictly limited, role-based, and fully logged.
Metrics per role
Roles only work if their success is measurable. This section suggests a few metrics per role; they belong in the metrics field of the role profile and in reporting (chapter D4). More than two to three metrics per role dilute the steering effect.
Product owner: goal contribution, usage rate, satisfaction, time and budget adherence.
Data owner: data quality and currency, approval speed, rule violations.
Data scientist: model quality, stability across scenarios, benefit versus baseline.
MLOps/platform: deployment time, error frequency, recovery time, resource efficiency.
Responsible AI: fairness indicators, explainability, fulfillment of obligations.
FinOps: cost per request, training, and product, forecast accuracy.
Scaling by company size
The role map describes functions, not positions: not every role needs its own person. This section shows how the same responsibilities are staffed depending on company size without losing the segregation of duties.
Area of responsibility
Up to ~50 employees
~50 to 250
250+
Strategy, prioritization, budget
Executive management in personal union, one monthly steering slot
One AI lead plus a small Portfolio Board
Executive sponsor, Chief AI Officer, Portfolio Board
Product ownership per use case
One person from the business unit, often part-time
Dedicated product owners
Product owners plus business analysis
Data (owner, engineering, data science)
One data-literate person, supplemented externally
A small data team
Separate roles
Technology and operations
Existing IT plus partners
ML and platform tasks as one team
Dedicated platform and operations teams
Security, compliance, data protection
Existing roles; approval stays separate from building
Part-time roles with independent approval
Independent functions incl. model risk management and audit
Enablement and FinOps
Integrated into HR development and controlling
Named part-time roles
Dedicated roles
One boundary holds regardless of size: whoever builds a model does not approve it. Security and compliance approvals stay separate even when development and operations are heavily bundled (see section Segregation of Duties).
Smaller organizations: roles are bundled (the product owner takes on business analysis; data engineer and ML engineer form one team). Governance stays lean: clear guardrails, short templates, few mandatory reviews with fast turnaround. A small set of binding standards (naming, versioning, model cards, approval evidence, a simple cost overview) is sufficient. Consistent adherence is what matters.
Large organizations: dedicated teams for platform, security, Responsible AI, FinOps, data management, operations. Tiered bodies (portfolio, architecture/security, operations), communities of practice, shared platforms, and independent roles for model risk management, compliance, data protection, and internal audit.
Checklist: practical rollout
The checklist walks through introducing the roles, from the role map to ongoing adjustment:
Role map created (people assigned, gaps named)
Role profile completed and filed centrally for every role, including deputy and deliverables
Decision rights assigned per role; security and compliance approvals independent of development and operations
RACI per use case maintained and reviewed at every milestone, with exactly one A per task
Segregation of duties implemented: development separate from approval, operations separate from audit, data approvals with the data owner, production access restricted and logged
Bodies established with clear mandates and meeting cadences
Templates made mandatory (model card, data card, evaluation, security, cost report)
Role staffing adapted to company size without giving up segregation of duties
Pilot product run through from intake to operations
Role-specific training and communities of practice set up
A small set of metrics per role defined and anchored in reporting
