Skip to content
NTPU AI Learn

IL 302 · Module 2

Operating Model and Organization

Design ownership of systems and data, a user-support model, a capability-building plan, and decision responsibility (RACI).

Start Section 1
  • Duration240 min
  • LevelArchitecture
  • PrerequisiteModule 1's investment portfolio and value ledger completed
0 / 4 completed

Learning objectives

  • Assign explicit ownership and update-decision authority for systems and data.
  • Design a user-support model covering first-line support, escalation, and training.
  • Use RACI to assign capability building and day-to-day decision responsibility to specific roles, not department names.

Ownership of systems and data

60 min

Behind one successful project, who actually owns the system?

During an IL 301 pilot, system and data ownership usually sits informally with the project team: if something breaks, you find the project lead. Once a project moves into steady-state operations, that informal arrangement has to become a formal organizational responsibility, or the system becomes an orphan with no real owner once the project ends and members move on.

Questions system and data ownership must answer
ItemQuestion to ask
System ownershipAfter formal handover, which role is responsible for operating this AI tool/integration and rolling out version upgrades?
Data ownershipWho is responsible for the ongoing classification, retention, and access management of the data this system uses and produces?
Content/knowledge updatesWhen the knowledge base or reference documents go stale or need revision, who has the authority to approve the update, and who actually does the work?
Budget ownershipWhich department's budget carries the ongoing licensing, operations, and reviewer-labor cost?

Warning

Common mistake: writing ownership as a department name like "the IT department" or "the customer-service department" instead of a specific role. Department names lose meaning when people move or the organization reorganizes; a formal operating model needs to name a specific position, with a handover mechanism when that position changes hands.
  1. Step 1
    List every data item and every component this system uses (reuse the IL 202 data inventory).
  2. Step 2
    Assign a specific role, not a department, to each of system, data, content updates, and budget.
  3. Step 3
    Write down what the handover procedure is if the current role holder leaves or moves; no handover procedure counts as a gap.

Key takeaway: Once the pilot ends, the temporary "project lead" role has to be broken down into specific, handoff-ready formal ownership, or the system becomes an orphan nobody manages.

User-support model

60 min

User-support model: who does a user turn to when the AI gets it wrong?

The biggest difference between steady-state operations and a pilot is that users no longer have a project team on standby. A user-support model has to clearly answer what to do first, and who to go to, when the AI tool produces a bad output, the system goes down, or a user is unsure whether to trust the result.

Three tiers of a user-support model
TierHandlesTypical situation
First line (the user)Uses the judgment criteria learned in training to decide first whether the output is trustworthy or needs human reviewThe AI output looks reasonable but the user is not fully sure
Second line (internal support desk)Handles clearly wrong outputs, operational issues, and escalation requests, and logs the issue typeThe AI gives a clearly wrong answer, or the system behaves abnormally
Third line (technical/governance owner)Handles systemic problems, data or access gaps, and decides whether a feature needs to be pausedThe same type of error keeps recurring, indicating a systemic issue rather than a one-off case

Info

The user-support model must include training: users need to know when to hand off to a human, rather than pressing ahead through any uncertainty, or escalating to the third line over every small issue. This judgment criterion is exactly what IL 202's incident-drill runbook (Module 3) already produced; here it has to be turned into part of the formal support process.
  1. Step 1
    Assign a specific role and a real, actually-monitored contact channel to each tier, not a department inbox.
  2. Step 2
    Set the concrete criteria users should use to decide whether to hand off to a human, and include them in training.
  3. Step 3
    Design an issue-logging mechanism so recurring error types can be spotted by the third line and escalated to systemic-issue handling.

Key takeaway: A system with no clear support tiers leaves users either blindly trusting the AI output or too afraid to use it at all; neither is what steady-state operations should look like.

Capability building and decision responsibility (RACI)

60 min

Use RACI to assign capability building and day-to-day decision responsibility

RACI tags every piece of work or decision with four relationships: Responsible (does the work), Accountable (ultimately owns the outcome, exactly one person), Consulted (asked for input beforehand), and Informed (told afterward). Steady-state operations for an enterprise transformation need RACI to spell out capability building and day-to-day decisions clearly, instead of improvising who is responsible every time something goes wrong.

RACI example fields (using "knowledge-base content update" as the decision)
ActivityResponsibleAccountableConsultedInformed
Knowledge-base content updateContent operations staff (a specific role)Customer-service process ownerLegal/compliance (when a policy change is involved)The whole customer-service team
User-training scheduleTraining leadCustomer-service process ownerTechnical administrator (provides system-operation content)Users taking part in the training

Warning

Common mistake: putting two or more roles in the Accountable column for the same activity, or leaving it blank. Accountable can only be one person; if it feels like two people need to share it, that usually means the activity should be split into two smaller decisions handled separately, rather than leaving responsibility fuzzy.
  1. Step 1
    List the capability-building activities (training, onboarding, advanced-user development) and day-to-day decisions (content updates, exception handling, feature changes) steady-state operations need.
  2. Step 2
    Fill in the four RACI columns for every activity; Accountable gets exactly one specific role.
  3. Step 3
    Cross-check this RACI table against the ownership table from Module 2 Slide 1 to make sure responsibilities do not contradict each other.

Key takeaway: RACI's value is not in filling in a table; it is in forcing the question of exactly who to go to when something goes wrong, and making sure the answer is a single name.

Example: operating model and RACI

60 min

Example (SYN-CS-001): the customer-service knowledge assistant's operating model and RACI

Continuing Module 1's synthetic case, Demo Service Company A's customer-service knowledge assistant has moved from a pilot in the customer-service department into limited steady-state adoption. The following shows a simplified operating model and RACI summary you can compare against your own project's version.

Customer-service knowledge assistant system and data ownership (synthetic example)
ItemOwning role
System operationsTechnical administrator (a synthetic role, not a department name)
Data ownershipCustomer-service process owner, working with the privacy owner on retention and access
Content-update approvalApproved by the customer-service process owner, executed by content operations staff
BudgetCustomer-service department's annual operating budget, including AI tool licensing and reviewer hours
Customer-service knowledge assistant user-support tiers (synthetic example)
TierRole and channel
First lineCustomer-service agents decide whether to hand off to a human, per training criteria
Second lineInternal support desk (synthetic role); handles clearly wrong outputs and operational issues, and logs issue types
Third lineTechnical administrator and privacy owner; handle recurring systemic issues and access gaps
Check yourself

In a RACI table, the Accountable column for "knowledge-base content update" lists both "customer-service process owner" and "technical administrator." What is the biggest problem with this?

In a RACI table, the Accountable column for "knowledge-base content update" lists both "customer-service process owner" and "technical administrator." What is the biggest problem with this?

Key takeaway: Putting ownership, support tiers, and RACI side by side in one document is the only way to spot gaps or overlaps in who is actually responsible for what.

Save as PDF

What next?