Intended use
What deliverable or operating decision does the output support, and what must the automation never decide?
DefinedGovernance begins before confidential material enters the workflow.
A useful scope identifies the intended use, source authority, representative test, decision rights, operating responsibility, environment, evidence, and explicit exclusions before a build is proposed.
Six questions define the operating envelope.
If the engagement cannot answer them, the workflow is not ready to automate.
Source authority
Which systems, files, versions, data classes, and access routes are permitted, and who can authorize them?
NamedAcceptance test
Which representative examples, measures, thresholds, error classes, and reviewer checks determine usability?
MeasuredDecision rights
Who can correct, reject, approve, release, escalate, stop, and change the workflow?
AssignedOperating responsibility
Who owns access, support, incidents, monitoring, change control, retention, deletion, export, and exit?
RecordedExplicit exclusions
Which data, systems, roles, decisions, and outcome claims remain outside the engagement?
VisibleAutomation may prepare. Authority remains assigned.
The proposal names the people and qualified roles required for interpretation, review, approval, release, representation, and escalation.
ActivityDurabilityClient / qualified role
Prepare and mapMay own within scopeAuthorizes sources and intended use
Test and classify exceptionsMay execute agreed methodApproves acceptance and escalation rules
Regulated interpretationMay coordinate supporting materialOwns judgment and approval
Release or submission decisionNo independent authorityOwns final decision
Deployment is a responsibility map, not an assurance label.
Client-controlled cloud, on-premises, hybrid, and open-source-capable directions can be assessed. The label alone establishes none of the outcomes buyers care about.
Environment
Tenancy, hosting, identity, network paths, model/provider use, logs, backups, and data location.
Operation
Installation, support, observability, incidents, updates, access review, change control, and exit.
Evidence
Intended use, testing, security/privacy analysis, validation responsibility, procedures, acceptance, and review.
What the public site will not imply.
A controlled workflow can support a regulated process. It does not become compliant, validated, secure, private, or fit for use because of a model name, integration, audit history, or deployment label.
Does on-premises mean private?
Not by itself. Privacy depends on the complete data flow, access, storage, model use, support, retention, deletion, and incident responsibilities.
Does an audit trail establish Part 11 or GxP compliance?
No. Applicable requirements, intended use, the complete system, procedures, validation evidence, records, access, operations, and accountable client roles must be assessed.
Do you guarantee extraction or generated-output accuracy?
No. Output is measured against an agreed representative set and reported with denominators, limits, error types, and exceptions. Fitness for use remains engagement-specific.
Can the workflow run without AI?
Yes. AI use is task-specific and requires client permission. A non-AI route can remain available when the material or environment requires it.
Put the controls in the first scope.
Bring the workflow, intended use, source types, reviewer, timing, and environment at a non-confidential level. We will identify the evidence and exclusions before proposing a build.