Skip to main content
Planning draft · unlisted page

A roadmap for AI-readiness in a national statistical office

This page sets out the components of an operational project that would support one national statistical office through the full implementation of AI-readiness: governance, people, infrastructure, metadata, access for AI systems, AI in production, and measurement. For each component it states what the office needs, what the project would finance, what the program provides today, and where the program could expand. The sequence follows the dependencies between the dimensions of the assessment framework.

Investment areasExpansion opportunitiesReadiness gatesOperational companion
Phases
4
Investment areas
15
Program contributions
52
Expansion opportunities
33
Scope

The project and the program

Two actors appear on this page. The project is the operational engagement that finances the office. The program is AI for Data - Data for AI, which provides the tools, methods, cookbooks, and advisory work that the project applies.

The project finances

  • Staff: recruitment, secondment, and retention of the roles the components need.
  • Assets: servers, hosting, gateways, and the development environment.
  • Training: three cycles that follow the components as they arrive.
  • Legal work: review of the statistics act and drafting of licences and terms of use.
  • Adaptation: the work of fitting program components to the office's languages, classifications, and systems.

The program provides

  • The assessment framework that gives the project its components and its results indicators.
  • Open-source tools at the status stated on the tools page: the Metadata Editor, NADA, the Data360 MCP server, the chat application, Proof-Carrying Numbers, anomaly detection, the PI-FT toolkit, and the end-to-end reference implementation.
  • The cookbook series as the method and the training material of each component.
  • Advisory work during assessment, design, and the phase gates.
  • Shared resources that the office joins at the end: the Global Question Bank, evaluation suites, and a peer network of offices.
Available
Available now

The program provides this today as an open-source tool, a method, a cookbook recipe, or a reference implementation.

Adapt
Adaptation financed by the project

The program has the component. The project finances its adaptation to the office: languages, classifications, existing systems, and staff.

Expand
Expansion opportunity

The program does not provide this yet. The project is an occasion to develop it once and reuse it in later engagements.

Project
Project only

The project finances this outside the program: procurement, salaries, legal drafting, and facilities.

Sequence

Four phases with entry gates

The phases are ordered by what each one depends on. A phase opens when its gate is met, so the duration of each depends on the office. The framework's pathway for early-stage organizations gives the same order: quality control, metadata standards, a searchable catalog, and API access under a clear licence come before agentic and generative access.

  1. 0

    Assessment and project design

    Entry: a request from the office and agreement on the scope of the assessment.

    The office is scored on the twelve dimensions of the assessment framework. The scores, the gaps between current and target levels, and the dependencies between dimensions give the project its components and their order. The results framework of the project takes its indicators from the assessment so that a re-assessment at the end measures the change.

    The project finances

    • A project preparation mission with the office and its main data users.
    • An inventory of the systems, datasets, classifications, and staff the office already has.
    • A procurement and staffing plan derived from the component list.

    The program provides

    • The assessment framework and its scoring, applied with the office.
    • The operational companion that maps each dimension to tools and recipes.
    • The investment view of the cookbook, which gives effort, roles, and kinds of cost per recipe.
  2. 1

    Foundations

    Entry: a signed project with a named project implementation unit inside the office.

    The office puts in place what every later component depends on: an AI-use policy with an owner for each component, a metadata standard applied to the catalog, a quality procedure with status codes and a revisions log, a licence on every published product, and a catalog with stable URLs. Training starts with the staff who will own these artefacts.

    The project finances

    • Staff time of curators and methodologists, which is the largest cost of this phase.
    • A catalog host and version control if the office has neither.
    • Legal review of the statistics act and of data licences for use in AI.
    • The first training cycle for curators, methodologists, and the dissemination unit.

    The program provides

    • The Metadata Editor, the metadata schemas, and the NADA catalog.
    • The completeness checker, the dictionary check, and the release procedure of the cookbook.
    • The AI-use policy template and the component register.
    • The cookbook as the training material of the first cycle.
  3. 2

    AI-ready operations

    Entry: the foundations are in production and the catalog passes the completeness profile.

    The office adds the components that make its products usable by AI systems and that use AI in production under review. Semantic search and a documented API sit beside the catalog. An MCP server and an assistant that verifies every number sit on the API. Anomaly detection, classification and coding, and metadata review run with a human decision on every output. Evaluation suites gate each change.

    The project finances

    • A GPU server, or hosted-model usage for public inputs, and an API gateway with monitoring.
    • A data science and engineering team inside the office, recruited or seconded.
    • Reviewer time for calibration samples and a monthly sample of answers in each language.
    • The second training cycle, which covers model operation, evaluation, and review.

    The program provides

    • The Data360 MCP server, the Proof-Carrying Numbers packages, the end-to-end reference implementation, semantic search, and anomaly detection, at the status stated on the tools page.
    • The evaluation suite method and the question sets of the cookbook.
    • The small and open models guidance for sizing and serving a local model.
    • Adaptation of models and retrieval to the office's languages and records.
  4. 3

    Institutionalization

    Entry: the AI-ready components have run through at least one full release cycle with their evaluation suites.

    The office owns and funds the components from its own budget, publishes a statement of model use with each release, monitors data use, and re-assesses itself. The project closes with a re-assessment on the same framework and with the office contributing its question sets, evaluation suites, and records to the shared resources of the program.

    The project finances

    • Transfer of hosting, maintenance contracts, and model licences to the office's own budget.
    • A final re-assessment and a published results report.
    • Training of trainers so that the office runs later training cycles itself.

    The program provides

    • The data-use monitoring method and its reports.
    • The statement of model use and the governance recipes of the cookbook.
    • Shared resources that the office joins: the Global Question Bank, evaluation suites, and the peer network of offices.
External adoption

Readiness gates for inviting other institutions

Three gates separate showing the tools from asking another institution to adopt them, and adoption from presenting an implementation. Each gate is a set of conditions with the evidence that shows it is met. The gates carry no dates; the program passes one when its conditions hold.

  1. 1

    Ready to demonstrate

    Sufficient for: a technical exchange with other institutions, with a live walkthrough of the tools.

    The services in operation are stable enough for a walkthrough on live systems, the documentation is public, the known limits of each tool are stated, and the path from an assessment to the tools is explained on one page.

    Conditions

    • Every tool on the tools page has a status with evidence, an owner repository, and a known-limits list.
    • The services in operation have run without an unplanned outage during the preceding review period, as the operator records it.
    • The end-to-end reference implementation runs from a clean checkout in CI.
    • The implementation hub explains the areas and the order of the work without reference to internal documents.

    Evidence

    • The tools page with its checked dates.
    • The CI run of the reference implementation and the cookbook scripts.
    • The operator's availability record for the services in operation.
  2. 2

    Ready for external adoption

    Sufficient for: inviting an institution to become a technical early adopter of a named tool.

    A technical team outside the program has installed or integrated the tool in its own environment from the documentation, run the acceptance tests, and operated it without engineering support from the program beyond answers on the issue tracker.

    Conditions

    • At least one installation test by an outside team is recorded as an issue, passed or failed, and every blocker it found is fixed or documented.
    • The tool has versioned releases with a documented rollback, or a pinned commit with the same effect.
    • The tool has a user guide, an installation guide, and a description of its API where it has one.
    • Security notes for the deployment exist: what the tool stores, what it sends to a provider, and what access control the adopter must add.

    Evidence

    • The installation test issues, with elapsed time, platform, and blockers.
    • The release page or the pinned commit named in the installation guide.
    • The deployment and security pages of the tool's documentation.
  3. 3

    Ready to showcase an implementation

    Sufficient for: presenting the program as a tested approach, with an implementation and a collaboration behind it.

    At least one organization has implemented the recipes and the tools in its own operations with documented results, and at least one institutional collaboration has moved to a technical assessment, an integration test, or an agreed implementation plan.

    Conditions

    • An implementation with named operational outcomes: records documented, products served, answers verified, with the figures the organization agrees to publish.
    • A re-assessment on the framework, compared with the baseline, with the evidence rows that support each changed score.
    • Lessons written for the next organization: what the guides lacked, what took longest, what the organization changed in the tools.
    • A collaboration with another institution recorded as a plan, a test, or an assessment, with the institution named in the record.

    Evidence

    • The implementation case, published with the organization's agreement and nothing it has not approved.
    • The two readiness profiles and the evidence register.
    • The collaboration record.

A tool can pass the second gate while its country adoption is still at a pilot stage, and a pilot can succeed in one country without showing that another institution can deploy the tool alone. The gates keep the two claims apart. The status of each tool against the first two gates is on the tools page.

Components

Investment areas by phase

Each row is one component of the project. The dots show the phases in which it is active, and the badges show the kind of contribution the program makes. Select a row to read what the office needs, what the project finances, what the program contributes, where the program could expand, and the evidence the area produces for the assessment form.

Investment areaDimensionsPhase 00Phase 11Phase 22Phase 33Program contribution
Governance and legal
1.1AvailableAdaptExpand
1.22.6AvailableExpand
People and training
1.31.5AvailableAdaptExpand
1.3AvailableAdaptExpand
Infrastructure and assets
1.4AvailableAdaptExpand
Metadata and catalog
2.1AvailableAdaptExpand
2.2AvailableExpand
2.3AvailableAdaptExpand
Access for AI systems
2.4AvailableExpand
2.5AvailableAdaptExpand
AI in production
1.42.2AvailableAdaptExpand
2.52.6AvailableExpand
1.41.5AvailableExpand
Measurement and sustainability
1.12.5AvailableExpand
1.51.6AvailableExpand
Governance and legal

AI strategy and governance of the office

Phases 0, 1, 3Assessment dimensions 1.1

A written position of the office on AI: which tasks a model may assist, which decisions stay with people, who owns each AI component, and how model use is reported to users of the statistics. The assessment framework scores this under strategy and governance, and it gates the dimensions that follow.

The project finances

  • Management time for a strategy adopted at the level of the head of the office.
  • A governance board that meets on a schedule and records its decisions.

The program contributes

Expansion opportunities

  • A model AI strategy for a statistical office, written at the level of a national statistical plan, with the policy and register as its annexes.
  • A governance review service: a short structured review of the policy, register, and board records, run before each re-assessment.

Evidence for the assessment

  • The adopted AI-use policy
  • The component register
  • Minutes of the governance board
Where the program could grow

Expansion opportunities

These are the components the program does not provide today and that a project of this kind would need. Each one is written so that it is built once for the first office and reused in later engagements. They are grouped by the investment area that needs them.

Governance and legal

AI strategy and governance of the office
  • A model AI strategy for a statistical office, written at the level of a national statistical plan, with the policy and register as its annexes.
  • A governance review service: a short structured review of the policy, register, and board records, run before each re-assessment.
Legal environment and data licensing
  • A legal checklist for statistics acts and data protection rules on the use of AI in production and on data for AI, with model clauses that a legal adviser can adapt.
  • A licence selector for statistical products that records the choice and the reasons in the catalog.

People and training

Roles and staffing
  • A fellowship or secondment scheme that places a data scientist from the program or a partner in the office for the AI-ready phase and pairs them with a counterpart.
  • A help desk for implementing offices, with a shared issue tracker and office hours.
Training and skills
  • A structured curriculum with modules, exercises, and a completion record for each role, built from the cookbooks and maintained with them.
  • A training-of-trainers module so that an office runs later cycles itself.
  • A sandbox environment with the running example organization and the tools installed, so that a cycle starts without a local setup.

Infrastructure and assets

Compute, hosting, and model serving
  • A reference architecture for a statistical office, with deployment packages (containers and configuration) for the catalog, the search index, the API, the MCP server, and the model server.
  • A hosted option through a partner for offices that cannot run a server, with confidential inputs kept out of it.

Metadata and catalog

Metadata standards and ontologies
  • A migration tool from the common legacy formats of statistical offices into the editor.
  • Integration of the Global Question Bank into the editor, so that a questionnaire is documented against shared concepts as it is entered.
  • An ontology and knowledge graph service over the office's records, as a shared component.
Quality control with model assistance
  • A review board toolkit: the board's terms of reference, a decision record format, and a dashboard of flags and decisions over releases.
  • Shared evaluation suites across offices for the common tasks, so that an office starts from a suite and adds its own cases.
Searchable catalog and discovery
  • A semantic search module packaged for NADA, so that an office installs search by meaning without building it.
  • Multilingual retrieval models for the languages of the regions where the program works, trained once and shared.

Access for AI systems

API access with provenance
  • An API package for NADA and for the common indicator databases of statistical offices, with provenance fields, versioning, and an OpenAPI description out of the box.
  • A conformance test that an office runs against its API and attaches to the assessment form.
Agentic and generative access
  • A deployable MCP server for NADA and for SDMX services, so that any office with a standard catalog or API exposes it to agents with configuration alone.
  • A verified assistant as a hosted service for offices that publish public data only, run by a partner under the office's terms of use.
  • A registry of statistical MCP servers that AI vendors can use to prefer official sources.

AI in production

AI-assisted data production
  • National classification coders as shared models: one per classification family, adapted per country from a common base and evaluated on a shared suite.
  • A document-extraction service for the archive of printed statistical publications, which many offices hold and have never digitized as data.
Synthetic data and ML-ready datasets
  • A synthetic data service inside the Microdata Library pattern, so that a catalog offers a synthetic file for each public-use dataset.
  • Croissant records generated from the catalog, so that ML-ready datasets are listed where model builders look.
Small and open models
  • A model catalog for statistical offices: open models evaluated on statistical tasks, with licences classified and sizing recorded, updated as models change.
  • Adapted models for the languages of implementing offices, released under open licences.

Measurement and sustainability

Monitoring of data use
  • A shared monitor of references to official statistics by AI systems, run by the program across offices and reported to each.
  • A data-use dashboard packaged for NADA and the API gateway.
Sustainability and re-assessment
  • A results framework template for projects of this kind, with indicators derived from the assessment dimensions and the evidence each recipe produces.
  • A maintenance subscription model under which a partner maintains the shared components and offices contribute cases.
People

Roles the project staffs

The components need these roles inside the office. Curators, methodologists, and subject-matter staff usually exist. The engineering and data science roles are the ones the project most often has to recruit or second.

RoleWhere it sitsWhat it ownsWhat the program gives it
Project coordinatorThe project implementation unit inside the officeRuns procurement, staffing, and the phase gates. Reports to the governance board.The phase gates and the component list of this page; the operational companion.
Metadata lead and curatorsThe dissemination or data management unitOwn the records, the completeness profile, the code lists, and the review decisions.The Metadata Editor, the schemas, the reviewer, and the dissemination and microdata cookbooks.
MethodologistThe methods or quality unitOwns the map of model-assisted tasks, thresholds, calibration samples, and the revisions log.The production, evaluation, and anomaly-detection resources.
Data engineerThe IT unit, recruited or secondedRuns the catalog, the search index, the API, the gateway, version control, and continuous integration.The reference implementations, the hosting notes, and the serving-to-agents cookbook.
Data scientistA new AI or data science unit, or the methods unitEvaluates and adapts models, builds the suites, and runs the model server.The small models, evaluation, and production cookbooks; the PI-FT toolkit.
Evaluation reviewerSubject-matter units, part timeLabels question sets, reviews samples of model outputs, and records decisions.The evaluation suites cookbook and the review formats of each recipe.
Legal adviserThe office's legal function or external counselReviews the act and the rules, drafts licences and terms of use.The licensing and access recipes; the checklist listed as an expansion.
Risks

Risks and responses

The foundations are skipped for the visible components.
The phase gates make the catalog, the policy, and the quality procedure a condition of the AI-ready phase. The assessment dependencies are the argument.
Trained engineering staff leave the office after the project.
Retention measures in the staffing component, training of trainers, and a help desk so that one departure does not stop a component.
Confidential records reach a hosted model.
An isolated segment for confidential inputs, a local model server, and the AI-use policy as a gate on every component.
Components are built once and not maintained.
Deployment packages under version control, evaluation suites in continuous integration, and recurring costs moved to the office's budget before closing.
The program cannot support several offices at once with bespoke work.
The expansion opportunities on this page are the shared components that make a second engagement cheaper than the first.
Boundaries

What this page leaves out

  • Budget figures and cost estimates. The kinds of cost are given per area; figures belong to the project document.
  • Dates and durations. The phases are ordered by dependencies and entered through gates.
  • The counterpart office, the financing instrument, and the funders.
  • Numeric targets. The results framework takes its indicators from the assessment dimensions once a counterpart is known.

This page is a planning draft and is unlisted. It is linked from the site footer only, and it is excluded from search engines and the sitemap. The assessment framework and the operational companion remain the public reference for the dimensions it cites.