One hundred days to establish a capability, not automate everything
This guide uses an illustrative scenario. People, volumes and decision rules explain a method; they do not describe a CYTIZEN engagement or client result. Sophie, programme director, is asked to turn AI experiments into usable services. She refuses to promise that every use will be industrialised within one hundred days. By day one hundred, she proposes a verifiable operating model and at least one workflow for which continuation, limitation or termination has been decided on evidence.
The operating model brings together business ownership, technical responsibility, data management, controls, support and funding. It is more than an AI committee or tool catalogue. Sophie selects a document-search assistant: it answers using authorised sources, approves no document and cannot act in other systems. That scope permits operational testing before introducing agents with execution rights.
Days 1–15: define the service and its mandate
The first phase produces a completed service record. Purpose: find an approved instruction. Population: authorised employees on a pilot site. Data: designated document corpus. Output: answer with source, version and date. Limits: no quality approval and no answer unsupported by the corpus. Owner: the business process owner. Operator: a named IT team. Stop authority: business owner or security lead according to cause. These fields are approved together.
The phase identifies issues requiring assessment: personal data, contracts, content rights and classification under applicable legislation. The AI Act timetable is checked against current Commission publications rather than treating one general date as applicable to all systems. Competent functions retain legal decision-making. The programme ensures that the decision is known before release and that its impact on scope is documented.
The first gate rejects three shortcuts: ownership assigned only within the project, unknown corpus rights and support relying on someone not committed to operations. Missing conditions may still permit isolated exploration, but the service is not presented as a release candidate. Schedule pressure must not turn uncertain accountability into an implicit operational risk.
Days 16–35: build the quality reference
Business experts prepare representative questions and difficult cases, recording expected answers, acceptable sources and required abstentions. Tuning data are separated from final decision data. Languages, sites and document types absent from testing are recorded. A campaign cannot demonstrate quality for a population it never examined.
The protocol distinguishes correct, grounded and usable answers. A response can be correct while citing the wrong document, making it difficult to verify. Another can quote accurately while omitting a crucial exception. Critical errors are defined beforehand: unauthorised access, dangerous instructions or confusion between approved versions and drafts. The scenario accepts none in the release set; that illustrative rule requires adaptation to actual criticality.
The discrepancy register records question, observed output, expected source, suspected cause, correction owner and retest. Sophie rejects incident lists without decisions. Corpus-related errors lead to data correction before a model change. Retrieval failures are fixed at retrieval. Prompt adjustment must not become the universal answer to rights, data or architecture problems.
Days 36–55: install operational controls
IT demonstrates permission propagation, removal of a document from the index and user revocation. Logs identify service versions, queried corpus and useful investigation events while limiting sensitive-data retention. Availability, cost and quality monitoring are established, with a fallback known to users. A visible interface does not constitute an available service when its sources cannot be reached.
An operating runbook covers rights leakage, unsupported answers, outage and cost drift. Each situation identifies the alert recipient, suspension procedure, user message and evidence to preserve. An operator other than the designer executes the procedure in a test environment. Transfer is incomplete if only the prototype author can stop the service.
The cost model includes inference, storage, indexing, monitoring, support, evaluation and human review. Cost per useful request retains rejected attempts in its numerator. Volume and document-length assumptions are recorded. The budget includes alerts and authority to limit use rather than relying on an invoice received after overspending. Cost control is an operating capability, not a late financial review.
Days 56–75: open a limited, reversible pilot
The pilot has an authorised population, fixed corpus and simple feedback channel. Users know the service's scope, how to check sources and when to return to normal search. Training covers work situations: ambiguous questions, missing answers and procedures from incompatible sites. Login rates do not establish adoption; the team observes whether users understand the output's limitations.
Sophie measures complete workflow time, including checking, against comparable tasks without the service. Comments are connected to authorised traces to distinguish interface issues, wrong answers and out-of-scope needs. Incidents are not removed from the assessment because users spotted them. Human detection is useful protection, but its reliability and cost must be assessed.
The pilot remains reversible. Existing procedures stay available and no compulsory dependency is created before approval. Suspension must not prevent business work. Withdrawal and restoration of the last acceptable version are actually tested. Requests to add a corpus or action permission trigger fresh risk assessment even when the interface stays unchanged.
Days 76–100: decide and transfer
The final phase does not seek to fill the report with successes. It assembles measured quality, incidents, test coverage, full cost, support capacity and residual risks. Management can continue within scope, expand conditionally, remain experimental or stop. Expansion requires its own owners and controls. Stopping can be a governance success if it prevents an uncontrolled dependency.
The handover pack contains the service record, decision log, evaluation protocol and results, stop and recovery procedures, support commitments, cost model and reassessment schedule. Operations accepts the pack and demonstrates the required actions. The programme does not leave before owners accept the risks they will carry. Extensions after day one hundred belong to a separate plan grounded in the established capability.
In practice: a decision to limit scope
Here, the assistant performs correctly on pilot-site procedures but fails to distinguish local versions in an international corpus. Sophie recommends retaining local use and deferring expansion. The limitation is not buried as an invisible technical detail. The business owner approves it, users see it and the backlog identifies evidence needed to reopen the decision. No industrialised-use count is reported without a definition and acceptance.
Adapt the hundred days to context
In regulated organisations, process and change validation may constrain what is achievable in one hundred days. In legal services, document rights and approval authority structure the pilot. For an IT agent able to act, add permitted-tool lists, least-privilege identities, execution limits and human approvals. The timetable is a preparation aid, not grounds for opening before these conditions are demonstrated.
Sources, method and limitations
Primary sources checked on 4 October 2026. This timetable is an educational method, not a normative requirement. It guarantees neither compliance, quality nor financial gains in any particular organisation.