Skip to main content
Bureau of AI
Category: Roles & Accountability

Model Developer

Also known as: AI Model Developer
Simply put

A model developer is a person (or team) responsible for building models, including designing, training, and refining them so they perform an intended task. In an AI context, this typically involves creating, training, and optimizing artificial intelligence models. The exact scope of the role varies by organization and by the type of model being built.

Formal definition

As commonly defined, a model developer is the individual or function responsible for creating a model, which in the AI setting includes designing, training, and optimizing artificial intelligence models. Some sources scope the role more narrowly to building or modifying models within a specific modeling language or platform, and others frame it broadly around end-to-end AI model creation and tuning, so the boundaries of the role are not standardized across the evidence. This entry describes the development function only; it does not address downstream roles such as model validation, deployment, or oversight, which are typically held by separate parties and, in many model risk management frameworks, are intentionally kept independent of the developer to preserve effective challenge.

Why it matters

The model developer sits at the origin point of a model's lifecycle, and the decisions made during design, training, and optimization shape the risks that every downstream party inherits. Choices about training data, model architecture, feature selection, and optimization objectives are typically where model risk is first introduced, which is why the development function receives close attention in AI governance and model risk management practices. Understanding who holds this role, and the boundaries of what it covers, is a prerequisite for assigning accountability across the model lifecycle.

The role also matters because its scope is not standardized. As the evidence shows, some sources describe a model developer narrowly as someone who builds or modifies models within a specific platform or modeling language, while others frame the role broadly around end-to-end AI model creation, training, and tuning. This variation means that organizations cannot assume a shared understanding of what a model developer does; the responsibilities must be defined explicitly within each organization to avoid gaps in ownership.

Because of the concentration of consequential decisions in this role, many model risk management frameworks deliberately separate the development function from validation and oversight. The developer builds the model; separate parties are typically responsible for independently challenging, validating, and monitoring it. Keeping these functions independent is intended to preserve effective challenge and reduce the risk that flaws introduced during development go unexamined. This entry describes the development function only and does not cover those downstream roles.

Who it's relevant to

Model Risk Managers
Model risk managers rely on a clear definition of the developer role to assign accountability and to enforce separation between development and independent validation. Because the scope of the developer role is not standardized across sources, they typically need to define its boundaries explicitly within their organization.
Data Scientists and AI Practitioners
Those who design, train, and optimize AI models often occupy the developer role directly. Understanding how the role is scoped—narrowly to a specific platform or broadly across end-to-end creation and tuning—helps clarify what falls within their responsibility and what is handed to separate downstream functions.
Auditors and Compliance Officers
Auditors and compliance officers examine whether development responsibilities are documented and whether the developer function is kept independent of validation and oversight, consistent with common model risk management practice. Variation in how the role is defined across organizations is itself a point of attention when assessing control gaps.
AI Governance Specialists
Governance specialists use role definitions like this one to map accountability across the model lifecycle. Establishing who counts as a model developer, and where that role ends, supports clear ownership structures and helps avoid ambiguity between the development function and downstream deployment or oversight roles.

Inside Model Developer

Model design and construction
The model developer is typically the individual or team responsible for specifying, building, and documenting a model, including data selection, feature engineering, algorithm choice, and calibration.
Developer documentation
Developers generally produce documentation describing model purpose, assumptions, limitations, data sources, and methodology, which commonly forms the basis for later independent review and validation.
First line of defense positioning
In many governance frameworks that use a three-lines-of-defense structure, model development sits within the first line, meaning developers own and manage the risks they create rather than independently reviewing them.
Distinction from the validator
The developer's role is functionally separated from independent validation. In model risk management practice, as commonly framed by guidance such as SR 11-7, the party that builds a model is generally not the same party that provides effective challenge through validation.
Support for ongoing monitoring
Developers often contribute to monitoring design and remediation by identifying performance thresholds and known limitations, though ongoing monitoring responsibilities may be shared with or handed to other functions depending on the organization.

Common questions

Answers to the questions practitioners most commonly ask about Model Developer.

Is the model developer the same as the model validator?
No. In many model risk management frameworks these are deliberately separate roles that should maintain independence. The model developer builds and documents the model, while validation is typically performed by a party not involved in development to provide an objective, independent challenge. Conflating the two undermines the separation of duties that frameworks such as those historically framed by SR 11-7 emphasize. Where the same individual both builds and validates a model, that independence is compromised, though the degree of separation expected can vary by institution size and risk profile.
Does the model developer own the model risk?
Not in the sense that accountability rests solely with them. The developer typically sits within the first line of defense and is responsible for building the model soundly and documenting it. However, ownership of the associated risk and accountability for its use commonly rests with business or model owners and, ultimately, with governance bodies, while the second line provides oversight and challenge. Treating the developer as the sole owner of model risk misplaces accountability that is generally distributed across the lines of defense.
What documentation is typically expected from a model developer?
In many frameworks, developers are expected to produce documentation sufficient for an independent party to understand, evaluate, and potentially reproduce the model. This commonly includes the model's purpose and intended use, data sources and assumptions, methodology, limitations, testing performed, and known weaknesses. The specific documentation standard varies by institution, model risk tier, and applicable guidance, so what is 'sufficient' should be defined by internal policy rather than assumed.
How does the model developer's role fit within the three lines of defense?
Model developers are typically positioned in the first line of defense, alongside those who own and use the model, since they are the parties directly building and operating it. The second line, often model risk management or independent validation, provides oversight and challenge, and the third line, internal audit, assesses whether the overall framework operates as intended. Because the boundaries between lines can differ across organizations, the placement of a specific development team should be confirmed against the institution's own governance structure.
What should a model developer do when they identify a limitation in their own model?
As commonly defined in model risk practice, developers are expected to disclose known limitations, assumptions, and weaknesses in model documentation rather than obscure them, so that validators, owners, and oversight functions can assess residual risk. Identifying a limitation does not necessarily prevent a model's use, but it should inform any compensating controls, usage constraints, or conditions placed on the model. The handling of disclosed limitations is typically governed by internal policy and the applicable risk framework.
How is the developer role affected when a model is acquired from a third-party vendor rather than built in-house?
When a model is externally sourced, the development activity occurs outside the institution, but the responsibilities associated with the developer function do not fully disappear. Institutions commonly retain responsibility for understanding the model's methodology, assumptions, and limitations, and for obtaining documentation adequate for validation, even where the vendor considers aspects proprietary. Where such documentation is limited, this is generally treated as a source of additional risk to be managed. The precise allocation of responsibilities between vendor and institution depends on contractual terms and applicable guidance.

Common misconceptions

The model developer also validates the model.
Validation is typically performed independently of development to preserve effective challenge. In many model risk management frameworks the developer and the independent validator are deliberately kept as separate roles; conflating them undermines the segregation these frameworks intend.
A model developer's documentation constitutes model validation or approval.
Developer documentation describes how a model was built and its stated limitations, but it is generally an input to review rather than an independent assessment. Validation, verification, and any approval steps are commonly carried out by other parties.
The model developer is accountable for governance of the model.
Developers are typically responsible for building and documenting the model within the first line, but broader AI governance, such as oversight structures, policy, and accountability, usually extends beyond the developer to second and third lines and senior management. Development and governance overlap but are not the same.

Best practices

Maintain thorough, transparent documentation of data sources, assumptions, methodology, and known limitations so that independent reviewers can perform effective challenge without relying on informal knowledge.
Preserve separation between development and independent validation, avoiding self-validation of models you build.
Explicitly record the model's intended use and boundaries so downstream users and monitoring functions understand where the model is and is not appropriate.
Identify performance thresholds and potential failure modes during development to support later monitoring, while recognizing that ongoing monitoring may be owned by other functions.
Distinguish clearly in documentation between verification of implementation and any claims about model soundness, leaving conclusions on soundness to the validation process.
Coordinate early with second-line risk and governance functions to confirm applicable internal policies and expectations, since requirements can vary by sector and organization.