Start with a readiness pilot, not an informal trial
A useful Enterprise pilot answers two questions at once: can the workflow create practical value, and can the organization govern it appropriately? The pilot should therefore include a bounded work type, named participants, approved provider, low-risk data boundary, fixed duration, explicit proof, and a security review plan. It should not quietly collect sensitive customer, employee, clinical, donor, public-record, or production data merely because the technical connection is easy.
Government organizations should use the Enterprise path because procurement, records, accessibility, security authorization, data classification, public notice, and jurisdiction-specific requirements may apply even to a small pilot. The exact obligations come from the customer and its advisors; the platform should provide accurate artifacts and configuration evidence rather than make legal conclusions for the buyer.
The review packet
| Review area | Questions to settle | Evidence to prepare |
|---|---|---|
| Purpose and ownership | What decision or work is supported, and who remains accountable? | Use-case statement, RACI, pilot scope, and prohibited uses |
| Provider and model | Whose credentials, billing, terms, region, retention, and model controls apply? | Provider configuration, data-use terms, allow-list, and owner |
| Data boundary | What customer, employee, code, operational, or regulated data may enter? | Data-flow diagram, classification, redaction, retention, deletion, and residency needs |
| Identity and access | Who can configure, assign, approve, review, export, and revoke? | SSO, roles, least-privilege mapping, joiner-mover-leaver process, and break-glass path |
| Context and connectors | What sources and external actions are allowed? | Context policy, connector scopes, resource allow-lists, credential custody, and revocation test |
| Execution and proof | Where does work run and what must prove success? | Isolation model, plan approval, proof profile, QA role, pull-request controls, and rollback |
| Audit and response | Can the organization explain a run and respond to failure? | Audit events, redaction rules, export, monitoring, incident contacts, and recovery exercise |
Choose pilot exit criteria before work begins
- Every material run can be reconstructed from source context through human acceptance.
- Unauthorized context, connector, repository, and action attempts fail safely and leave evidence.
- Provider credentials can be rotated or revoked without orphaning accountability.
- Required approvals become stale when the target or accepted specification changes.
- QA can return failed or inconclusive proof and prevent false completion.
- The organization can export the audit evidence it needs without exposing unnecessary story or secret content.
- The sponsor can explain what value was demonstrated and what remains unproven.
Expand by profile and work type
A successful pilot should not produce a blanket authorization for every agent and workflow. Expand by adopting reviewed governance profiles for defined work types, repositories, connectors, data classes, and approval paths. Track exceptions and incidents. Increase authority only where the evidence supports it. Keep higher-risk actions, production changes, sensitive communications, and accepted-risk decisions behind explicit human authority.
Commercial and legal boundary
Public pricing can show an Enterprise starting point and the capabilities commonly included. The actual proposal should state the provider model, regions, data categories, security-review support, environments, integrations, service levels, rollout phases, training, responsibilities, and assumptions. ScrumDo documentation can support the review, but it does not replace the customer’s legal, privacy, records, procurement, accessibility, or sector-specific analysis.
Key terms
- Readiness pilot
- A bounded engagement that tests practical value and governance controls before broader deployment.
- Data boundary
- The explicit data classes, sources, transformations, regions, recipients, retention, and prohibited content for the workflow.
- Expansion gate
- A documented decision point that must be satisfied before adding users, data, connectors, work types, environments, or agent authority.
Sources and standards context
- NIST AI Risk Management Framework CoreNIST describes governance as a continuous, cross-cutting function and calls for documented human oversight, roles, testing, and accountability across the AI lifecycle.
- ISO/IEC 42001:2023 AI management systemsISO describes an organization-wide management system for policies, objectives, processes, risk, transparency, and continual improvement in the responsible use of AI.
- CISA and NCSC Guidelines for Secure AI System DevelopmentThe guidance emphasizes secure-by-design ownership, transparency, accountability, and informed decisions across design, development, deployment, and operation.