AI Developer vs Deployer: Responsibilities and Handoffs
The difference between building an AI system and operating it in an organization. A practical guide to responsibility, decision ownership, and what must accompany a handoff.
Updated 7 min read
An AI developer builds or fine-tunes an AI system: they choose the model, shape its behavior, and are responsible for what it can and cannot do. An AI deployer takes that system and puts it to work inside an organization: they choose the use case, configure access, and are accountable for the outcomes it produces in their context. The two roles have different duties, different risks, and different answers for when something goes wrong. Tools like fenbs help both sides record who owns which decisions and what information must travel with a handoff.
In practice, one team often plays both roles—or the boundary shifts as a project matures. That is fine, but the responsibilities still need to be assigned, not left as shared assumptions. An assumption nobody recorded is a gap an audit will find.
| Dimension | Developer | Deployer |
|---|---|---|
| Primary accountability | System accuracy, safety, and design boundaries | Fitness for purpose and real-world outcomes |
| Key decisions | Model choice, training data, capability limits, safety mitigations | Use case scope, access controls, review process, user population |
| Risk exposure | Bias in training data, capability misrepresentation, undisclosed limitations | Unapproved use, inadequate supervision, harm to users or third parties |
| Handoff obligation | Document what the system does, what it cannot do, and known failure modes | Acknowledge receipt, confirm the use case is within scope, name a review owner |
What the developer's responsibilities include
A developer's primary obligation is accuracy about the system's capabilities. This means documenting what the model was trained to do, what it was not trained for, and what failure modes have been observed. If the system performs poorly on a class of inputs, or if it should not be used for high-stakes decisions without human review, that needs to be in the record.
Developers are also responsible for safety mitigations built into the system—content filtering, output restrictions, refusal behaviors. Deployers cannot add mitigations they do not know about, and they cannot compensate for gaps the developer did not disclose. When a deployer uses a third-party model through an API, the relevant documentation is the vendor's published model card or safety documentation.
The NIST AI Risk Management Framework at https://www.nist.gov/artificial-intelligence (opens in a new tab) provides a structured approach to characterizing AI risk, and many US organizations use it as a baseline for developer documentation obligations.
What the deployer's responsibilities include
A deployer's primary obligation is fitness for purpose: the system being deployed must be appropriate for the specific use case and the people affected by it. A model that works well for drafting marketing copy may not be appropriate for making recommendations about credit, benefits eligibility, or medical triage without significant additional controls.
Deployers are responsible for access controls, supervision, and review processes. They must decide who can use the system, what inputs are allowed, what outputs require human review before action, and how errors will be caught and corrected. These decisions belong in writing, not in a shared understanding.
Where US regulation applies—FTC guidance on AI, federal sector-specific rules for finance (SEC, FINRA), healthcare (HHS), or hiring—the deployer is typically the regulated entity. The developer builds the tool; the deployer is the one using it in a regulated context and bears the compliance obligation.
Where the two roles overlap
In small organizations and solo developer contexts, the same person often builds and deploys the same system. The distinction still matters: developer decisions (what the model does) and deployer decisions (how it is used in this organization) remain separable, even when one person makes both. Keeping them in separate records prevents later confusion about what was a design constraint versus what was an operational choice.
When organizations use third-party AI tools—connecting to an API or subscribing to a product—they are purely deployers. The developer obligations belong to the vendor. The deployer's job is to evaluate the vendor's documentation, determine whether the system is appropriate for their use case, and configure adequate controls around it. A vendor's terms of service is not the same as a fitness-for-purpose assessment.
Record who owns which decisions on both sides
fenbs keeps the developer and deployer decisions in one place: what the system is designed to do, which use cases the deployer has approved, who owns the review process, and what limits apply. When a question arises about who authorized something, the record is there. Add your first boundary decision today—use case scope, review owner, or a known limitation.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Handoff requirements between developer and deployer
A handoff from developer to deployer is not complete when the system is deployed. It is complete when the deployer has received, understood, and acknowledged the information they need to operate it responsibly. At minimum, the handoff should include: the system's intended purpose, its known limitations, any populations or use cases it should not be used for, and the developer's contact for questions.
- Intended purpose: what the system was designed and tested to do.
- Known limitations: documented failure modes, performance gaps, or conditions where accuracy degrades.
- Out-of-scope uses: cases where the developer tested and found the system unsuitable.
- Mitigation measures: what safety or quality controls are built in, and what the deployer must add.
- Point of contact: who to reach if a new failure mode is discovered after deployment.
The deployer's acknowledgment of the handoff should be equally specific. It should confirm the use case is within scope, name the review owner, and commit to the review process. An email saying "we received the model" is not the same as a documented fitness assessment.
Common accountability gaps in practice
The most common gap is an undocumented expansion of scope. An AI tool deployed for one task drifts into adjacent tasks that nobody formally approved. The developer did not document the expansion; the deployer did not assess it. When a problem occurs in the expanded use, neither side has clear records of who decided what.
The second common gap is a missing review step. The deployer's governance document says outputs are reviewed, but the review process was never written down, and under time pressure it gets skipped. An audit looking for evidence of human oversight finds nothing to check.
Both gaps are records problems, not technology problems. The system may be working exactly as designed while the accountability structure around it fails. Good records do not prevent every error, but they make it possible to investigate, correct, and learn from the ones that do occur.
fenbs keeps the developer-to-deployer handoff record in Where we left off and Decisions and rules. The next AI assistant working on a deployment task reads what the system was designed to do, what was out of scope, and who owns review before it acts. Save the handoff record once and it is available to every connected assistant on the project.
How to do this with fenbs
Whether you are the developer, the deployer, or both, the starting point is the same: write down the decisions you have made and who made them.
- Create a free account and set up a project for the AI system. Add a short description of what it is designed to do.
- Write the developer decisions in Decisions and rules: intended purpose, known limitations, and out-of-scope uses. Name the developer and the date.
- Write the deployer decisions separately: approved use case, user population, review process, and named review owner.
- Create a handoff task with a checklist. Mark it Done only when the deployer has confirmed receipt, reviewed limitations, and named a review owner.
- When scope expands, create a new task and a new deployment decision. Do not modify the original record—add to it so the history stays visible.
fenbs does not connect to your AI system, monitor outputs, or collect metrics. It holds the governance layer: who decided what, when, and why. For questions about AI use in development teams, the guide to solo developer AI coding agents covers the developer-side workflow.