Intelligence and Data FAQ: Governance, Architecture and Trusted Decisions

An intelligence and data capability connects governed records, analytical methods and operating decisions. It is more than a dashboard estate and broader than an artificial intelligence project. The useful question is whether a named person can make a better, timely and reviewable decision from information whose meaning, quality and limits are understood. This intelligence and data FAQ answers the architecture, governance, quality, privacy and delivery questions that determine whether that promise survives production.

Teams starting with strategy can use the intelligence and data practical guide; delivery teams can pair it with the implementation checklist. For model-heavy uses, the data and AI services FAQ explains additional evaluation and operating controls. The sections below focus on the common information foundation.

What should an intelligence and data program deliver?

Start with a decision inventory. For each decision, name the owner, cadence, current evidence, delay, cost of error, people affected and action that follows. A weekly inventory decision, a real-time fraud alert and a quarterly capacity plan need different freshness, confidence and review controls. If no action changes when an insight changes, the proposed output is probably informational rather than operational and should not receive the same investment priority.

Define a baseline before changing technology: time to assemble evidence, reconciliation effort, disputed definitions, correction rate and outcome variation. Then state a testable improvement, such as reducing the time to identify delayed orders while keeping false escalation below an agreed threshold. This prevents the program from measuring success through data volume, dashboard count or model accuracy alone. Intelligence is valuable only when it changes a legitimate decision without hiding uncertainty or transferring unreasonable work to another team.

Who owns data, metrics and decisions?

Assign three responsibilities explicitly. A business data owner authorizes purpose and acceptable use; a technical steward maintains definitions, quality rules and lineage; a decision owner accepts how the information is used. One person may hold more than one role in a small organization, but the decisions remain distinct. A central data office can provide standards and shared tooling, while domain owners retain accountability for what customer, policy, asset or transaction fields mean in practice.

Maintain a catalog for critical products, not merely raw tables. Record purpose, authoritative source, schema, calculation, refresh, quality status, sensitivity, retention, users, downstream dependencies and support contact. The NIST Research Data Framework provides lifecycle-oriented topics spanning governance, quality, privacy, preservation and reuse. Its research context should be adapted to the organization rather than treated as a certification, but the lifecycle discipline is broadly useful.

Which data intelligence architecture fits the need?

Separate source systems of record, integration, governed storage, transformation, analytical serving and consumption. The labels warehouse, lakehouse, mesh or fabric do not remove the need to define authority at each boundary. Batch pipelines suit stable periodic decisions; event streams suit narrow low-latency signals; direct federation may be appropriate when copying is restricted or freshness dominates. Many portfolios need a combination. Choose per decision and preserve a reconciled path back to the record of origin.

Use versioned data contracts for important interfaces. A contract should describe fields, semantics, identifiers, allowed values, service expectations, change notice and the behavior of corrections. Test schema and semantic compatibility in delivery pipelines. Consumers should know whether an absent value means unknown, not applicable, not collected or failed processing. Those meanings affect denominators, model features and operational alerts, so silently coercing them into zero or an empty string is a business error rather than a cosmetic cleanup.

How is data quality made measurable?

Quality is fitness for a stated use. The UK Government Data Quality Framework emphasizes knowing users, assessing quality through the lifecycle, communicating limitations and addressing issues near their source. Translate that into rules tied to decisions: identifier uniqueness for matching, completeness of required fields, validity against business constraints, timeliness for the decision window, consistency across replicas and accuracy confirmed against an authoritative reference.

Every rule needs a scope, threshold, observation window and owner. A global 99 percent completeness figure can conceal a failed region or product. Monitor distributions and segments relevant to the decision, route failed records to a visible exception process and preserve original values for investigation. Reconciliation should compare counts, financial totals and state transitions at source, transformation and serving layers. Fix recurring defects at collection or process design instead of accumulating downstream patches whose logic no one can explain.

How should privacy and security shape analytics?

Document purpose, legal authority and affected people before collecting or linking data. Minimize fields, precision, population and retention to what the decision requires. Separate identity from analytical attributes where feasible, protect re-identification keys, and prevent analysts from exporting unrestricted row-level data. The NIST Privacy Framework helps organizations connect data processing with privacy risk; it does not replace the laws, regulator guidance or individual rights that apply in each jurisdiction.

Apply service identities, least privilege, encryption, secrets management, network controls and immutable audit records across ingestion, transformation, notebooks, semantic layers and exports. Production access should be time-bounded and reviewable. Threat modeling must include inference, linkage, poisoned source data, altered calculations, unauthorized model features and misleading visualizations. Test restoration of data, metadata, code and keys together: a warehouse restored without current transformation definitions or access policy cannot recreate a trustworthy analytical state.

When should intelligence include predictive or generative AI?

Use AI when a probabilistic method improves a bounded task and can be evaluated against a credible baseline. Forecasting demand, classifying documents and summarizing evidence have different failure modes. Define the output's role: advisory, prioritized for review, or authorized to trigger an action. The NIST AI Risk Management Framework organizes work around Govern, Map, Measure and Manage and states that risk management is continuous; its current 1.0 edition is under revision, so record the version used.

Build evaluation sets that represent normal, difficult, rare and adversarial cases. Compare outcome quality, subgroup effects, calibration, human review, latency, privacy, security and full unit cost. For generative answers, retain citations or source passages and test unsupported claims. For predictive scores, validate whether thresholds remain appropriate as prevalence changes. Monitor deployed model, feature, prompt and retrieval versions. A model should be suspended when upstream meaning changes, evidence falls below limits or the fallback process cannot protect affected people.

What is a practical six-stage delivery path?

• Frame one decision, its owner, baseline, affected population, consequence and measurable improvement.
• Trace authoritative records, definitions, lawful purpose, quality limitations and current reconciliation work.
• Design the smallest architecture that meets freshness, resilience, privacy and integration requirements.
• Build a thin end-to-end product with contracts, lineage, quality controls, access policy and observable failure states.
• Run representative decisions against the baseline; review errors, exceptions, user behavior, security and complete cost.
• Release gradually, monitor decision and data outcomes, govern changes and retire outputs that no longer justify their burden.

A thin slice should include the real source, transformation, metric or model, user workflow and feedback path. Synthetic demonstrations can test mechanics but cannot prove definitions, exceptions or adoption. Rehearse late data, duplicate events, source corrections, revoked access and dashboard unavailability. Capture an acceptance record containing owners, contracts, lineage, tests, privacy decision, risk treatment, runbook and rollback. Expansion then repeats this evidence path rather than copying a prototype into more domains.

How should the capability be operated and measured?

Organize durable ownership around data products and decisions, supported by shared platform, security, privacy and architecture capabilities. Product teams maintain contracts and service objectives; platform teams provide reusable ingestion, transformation, catalog, quality and observability services. Establish incident severity using decision impact, not pipeline color alone. A failed overnight feed to a monthly report is different from a silent unit conversion feeding real-time pricing, even if both produce one failed job.

Review a balanced scorecard: decision outcome versus baseline, adoption in the intended workflow, quality by relevant segment, time to detect and correct defects, policy exceptions, user challenge, reliability and full cost per useful decision. The OECD recommendation on data access and sharing highlights the need to balance benefits, risks and legitimate interests. That balance should appear in actual access decisions, not only in a data-sharing ambition statement.

Key takeaways

• Anchor intelligence and data work to named decisions and measurable outcomes.
• Make source authority, semantics, quality and lineage visible at every important boundary.
• Treat privacy, security and challenge as architecture requirements from the beginning.
• Evaluate AI as a probabilistic component with versioned evidence and a workable fallback.
• Operate data products through decision impact, service reliability, complete cost and explicit retirement.

Frequently asked questions

Do we need one enterprise data platform?

Not necessarily. Standardize the interfaces, identity, catalog, evidence and controls that reduce risk or duplicated effort. Different latency, sovereignty, analytical and operational needs may justify more than one platform. Govern the portfolio so users can find authoritative products and teams can trace movement across boundaries.

Should all intelligence be real time?

No. Freshness should match the decision window. Streaming adds state, ordering, replay, monitoring and support complexity. Use it where delay changes the outcome; otherwise a well-controlled batch may be easier to reconcile and operate.

Conclusion

A trustworthy intelligence and data capability is a chain of accountable meaning from source record to action. Frame the decision, assign ownership, design fit-for-purpose movement, prove quality and lawful use, evaluate advanced methods, and operate the resulting product with visible limits. That discipline turns analytical output into evidence people can use and challenge.