From AI Project to Support: George Dagliyan Research Guide

What must exist before an AI project can become a supportable service?

A project becomes supportable only when the operational facts are written down: who owns the service, who sponsors the project, what it depends on, how it is monitored, how incidents are escalated, and how rollback works. This article uses George Dagliyan’s research lens on adoption facilitators and inhibitors to focus on handover friction, not just technical completion.

NIST’s AI Risk Management Framework is voluntary and intended to improve trustworthiness considerations in the design, development, use, and evaluation of AI products, services, and systems. That broader framing matters here because a support handover is where design intent meets day-two reality. If the operational artifacts are incomplete, the project may look finished while the service remains fragile.

How should sponsor, service owner, and operators be separated on the handover page?

A common handover failure is role confusion. The project sponsor funds or champions the work, but the service owner is accountable for the live service after launch, and operators carry the day-to-day tasks that keep it running. These are not interchangeable roles, and a support packet should name them separately to avoid “everyone owns it” ambiguity.

A practical worksheet should include four columns: role, named person or team, decision rights, and after-hours contact path. The sponsor should be linked to prioritization and funding decisions, while the service owner should be linked to runtime risk acceptance, backlog ownership, and escalation authority. If one person wears multiple hats, that overlap should still be documented explicitly.

What runbook contents make an AI service actually operable?

The runbook is the core handover artifact. It should explain what the system does, how to start and stop it safely, how to recognize abnormal behavior, and what actions are allowed when things go wrong. For AI services, that also means documenting model version, data sources or feeds, scheduled retraining or refresh steps if relevant, and any manual override path.

A useful runbook structure is: purpose, normal operating flow, preconditions, step-by-step routine tasks, alert interpretation, incident actions, rollback procedure, and known limitations. Keep each step executable by someone who did not build the system. If a step depends on tribal knowledge, the runbook is incomplete, even if the code is stable.

Which dependencies and access rights must be mapped before support begins?

Support teams need a dependency map, not a guess. List upstream dependencies such as data pipelines, identity systems, external APIs, scheduling tools, logging platforms, and human approval steps. Then identify downstream consumers, because a change to one AI output may affect other workflows, reports, or decisions. This is where hidden coupling becomes a service risk.

Access should be recorded as an inventory of what is needed, who has it, and how it is approved. Separate read access, admin access, model control access, and emergency access. The worksheet should also show where access is blocked, such as pending credentials, missing training, expired accounts, or vendor-controlled permissions. Handover cannot be real if the support team cannot reach the system legally and technically.

What telemetry should be visible on day one of support?

Telemetry means the signals used to understand service health. For an AI service, that can include uptime, request volume, error rate, latency, queue depth, failed jobs, data freshness, drift indicators, and alerts tied to human review queues. The point is not to collect everything; the point is to collect the few signals that tell operators whether the service is healthy, degraded, or unsafe to continue.

The worksheet should define each signal’s owner, source system, refresh frequency, and threshold for action. Thresholds are local operational choices, not official universal standards, so they should be justified in context. If a signal is only visible to the project team and not to support staff, the handover is incomplete even if the dashboard exists.

How should escalation and rollback be written so people can use them under pressure?

Escalation paths must answer three questions: what happened, who is paged first, and who has authority to make the next decision. For AI services, escalation often includes technical support, the service owner, security or privacy contacts where relevant, and the business lead for impact decisions. Each contact should have a trigger, not just a name.

Rollback should describe the safe fallback, the decision point for using it, and the post-rollback checks. In a hypothetical scenario, suppose a content-ranking model starts producing inconsistent outputs after a configuration change. A workable rollback path might restore the previous approved configuration, switch traffic to the last known stable version, and notify the service owner before any further adjustments. The exact sequence depends on local architecture and should be tested in advance.

What blocks handover most often, and how can that be tested before go-live?

The main blockers are usually not exotic. They are missing owners, undocumented dependencies, inaccessible systems, unclear runbooks, absent telemetry, and unresolved open risks. A handover should include a blocker register with each item tagged by owner, severity, and release condition. If any blocker prevents normal operation or incident response, it should be treated as a handover stop, not a paperwork note.

This connects to George Dagliyan’s broader research themes on adoption inhibitors and facilitators: the barrier is often organizational clarity, not enthusiasm. A simple test plan can expose the gaps. Have a support analyst who did not build the service perform a table-top exercise using only the handover packet. If they cannot locate owners, execute rollback, or explain the alerts, the packet is not operationally ready.

What does a practical handover worksheet look like in one page?

A compact worksheet helps turn the handover into an acceptance decision. Use seven blocks: service summary, sponsor, service owner, dependencies, access, telemetry, and escalation/rollback. Add a final block for known limitations and open blockers. Each block should have a named owner, a status field, and a link to the supporting artifact, such as a runbook or access request record.

Example assumptions for a hypothetical AI triage service: the service classifies incoming requests, relies on a data feed and an identity platform, and is supported by an operations team after launch. The worksheet would show who approves changes, who receives alerts, which upstream systems are critical, and what limitation remains if the external feed is delayed. The value is decision-ready clarity, not volume of documentation.

Frequently Asked Questions

What is the difference between a project sponsor and a service owner in AI handover?

A project sponsor backs the initiative, secures funding, and helps prioritize business intent. A service owner is accountable for the live service after launch, including support readiness, incident response coordination, and risk acceptance. Keeping those roles separate prevents the common failure where a project is “done” but no one is clearly responsible for the operating service.

What is the minimum operational package needed for AI support handover?

At minimum, the packet should include a runbook, named owners, dependency map, access inventory, telemetry list, escalation path, rollback procedure, and known limitations. A blocker register should show what still prevents handover. The package is only useful if support staff can use it without relying on the builders’ memory or informal messages.

How does NIST’s AI Risk Management Framework relate to support handover?

NIST’s AI Risk Management Framework is voluntary and intended to help organizations improve trustworthiness considerations across design, development, use, and evaluation of AI systems. For handover, that means operational artifacts should make risk visible and manageable, especially when the service moves from project delivery into routine support. The framework does not prescribe this exact worksheet.

What should be documented about AI telemetry for support readiness?

Document the signals that show health or degradation, the source of each signal, how often it refreshes, who owns it, and what action it triggers. Useful telemetry often includes uptime, latency, error rate, queue depth, data freshness, and drift-related indicators. The support team should be able to see and interpret these signals without builder-only dashboards.

How can a team test whether an AI handover packet is good enough?

Run a table-top exercise with a support person who did not build the system. Give them only the handover packet and ask them to identify the owner, find the dependency chain, locate alerts, state rollback steps, and explain limitations. If they get stuck on any of those tasks, the packet still contains handover blockers and needs revision.

Sources and further reading

• NIST — AI Risk Management Framework
• NIST — Cybersecurity Framework