Knowledge Graphs and AI: Connect UK Business Data with Control

A knowledge graph can show that an invoice belongs to a supplier, a component appears in three products, and the policy governing both changed last month. That relationship layer can make AI retrieval more precise. It can also spread one bad identity match across every connected decision.

This guide reflects UK requirements and technical standards available on 31 July 2026. It is for UK organisations building business knowledge graphs, not a claim that one graph standard or architecture is legally required. Public bodies, regulated firms and organisations operating abroad must add their own sector and jurisdiction controls.

Begin with a decision, not a universal graph

“Connect all our data” is not a deliverable. Pick one decision with a known cost: identifying the current product specification for a service case, finding contracts affected by a supplier incident, or showing which customer record supports a renewal. Define the users, answer, maximum acceptable latency, evidence required and harm if the answer is wrong.

A graph is useful when relationships carry meaning that repeated joins or keyword search do not express clearly. It is not automatically better than a relational model, search index or master-data service. Our master-data guide for clean business records should often precede graph work; connected duplicates remain duplicates.

Write a competency-question set before choosing software:

• Which legal entity supplied this part during the affected period?
• Which current policies govern this customer and product combination?
• What source proves each relationship and when was it last checked?
• Which records conflict, and who can resolve the conflict?
• What would this answer have been at a previous point in time?
• Which user is permitted to see each node, edge and supporting document?

If a conventional query answers the question more cheaply and safely, use it.

Model provenance as carefully as the relationship

Every operational fact should retain its source, effective period, ingestion time, method, confidence, steward and review state. “Supplier A owns Site B” is incomplete if the graph cannot say whether it came from a signed contract, a public register or a model inference.

Keep raw assertions separate from curated facts. A source may say two records share an address; a steward may decide they describe one organisation. Store both the evidence and decision. Never overwrite history when a relationship changes.

The Government Data Quality Framework describes quality as fitness for purpose and recommends ownership, metadata, lifecycle assessment and communication of limitations. Its adoption request is directed at central government, but the practices are useful to private organisations. The government’s metadata standards collection, updated in April 2026, adds guidance on identifying and describing critical data assets.

Choose standards with their status visible

RDF represents information as subject-predicate-object statements. The W3C’s RDF 1.2 Concepts had a Candidate Recommendation Snapshot dated 7 April 2026. SHACL is a W3C Recommendation for describing and validating RDF graph constraints. SPARQL queries RDF graphs across diverse sources.

At the cutoff, SPARQL 1.2 Query Language was a Working Draft dated 5 June 2026, not a W3C Recommendation; SPARQL 1.1 remained the latest Recommendation. A production team should pin supported specifications and test suites rather than assume every draft feature is stable.

Standards improve portability only when identifiers, vocabularies and semantics are governed. Document whether a “customer” is a person, household, account or contracting entity. Define currencies, time zones, status codes and null meaning. Use validation shapes or equivalent schema rules in continuous integration and at ingestion.

The government’s Data Standards Authority illustrates a consensus-led approach to interoperability. Private-sector graphs need their own forum with domain owners empowered to approve terms, deprecations and mappings.

Build an evidence-linked AI layer

Do not expose the entire graph to a language model and ask for conclusions. Create a retrieval service that accepts an authorised question, resolves approved entities, runs allow-listed graph patterns and returns a bounded evidence subgraph. The answer generator should receive identifiers, facts, provenance and permitted source passages.

The operating sequence should be:

• Authenticate the user and purpose.
• Resolve named entities with confidence and alternatives.
• Apply policy before graph traversal, not after results return.
• Execute a versioned, bounded query or retrieval plan.
• Return facts with source and effective date.
• Generate a draft answer that cites those facts.
• Validate quantities, dates and prohibited claims deterministically.
• Log the query, policy version, graph snapshot and user outcome.

For high-impact use, require a steward or decision owner to confirm the answer. Our AI search and product-discovery guide covers ranking; graph retrieval adds relationships but does not remove the need for relevance and outcome testing.

Never interpret absence as proof. An edge may be missing because a feed failed, the vocabulary changed or access rules hid it. Answers should distinguish “the graph says no”, “no approved evidence was found” and “the user is not authorised to inspect that relationship”.

Treat entity resolution as a governed hypothesis

Entity resolution is the highest-leverage and highest-risk step. Start with deterministic identifiers from authoritative systems. Normalised name, address, email or device similarity can propose candidates, but sensitive or consequential merges need human review.

Store match features, score, threshold, model version and adjudication. Provide split and rollback operations. Evaluate false merges and missed matches separately by entity type and data source. A low overall error rate can hide damaging performance for names, scripts or address formats underrepresented in training data.

Do not use inferred ethnicity, health, vulnerability or protected characteristics to improve commercial matching without a documented lawful, necessary and fair purpose. Pseudonymous identifiers can still be personal data when re-linking is possible.

Privacy and relationship inference

Relationships reveal more than individual fields. A graph may infer family, employment, health, financial difficulty or political association from otherwise ordinary records. Define purpose and lawful basis before connection, and assess compatibility before reusing data from another process.

The ICO’s purpose-limitation guidance was updated in 2026 and requires purposes to be specified, explicit and legitimate. Apply minimisation to nodes, edges, features and retention—not only to source columns. Complete a DPIA where processing is likely to create high risk.

Access control must follow the path. A user authorised to view a supplier name may not be authorised to see its employee’s complaint, connected investigation or beneficial owner. Test inference attacks in which permitted fragments reveal a prohibited relationship. Keep production personal graphs out of development and evaluation; use synthetic or de-identified cases where possible, following our synthetic-data testing guide.

Security and data poisoning

Graphs concentrate valuable context and can amplify malicious input. Threat-model compromised feeds, forged identifiers, unsafe RDF parsing, query injection, denial-of-service traversals, prompt injection in documents and an attacker adding relationships that influence an automated decision.

Apply least privilege to ingestion, curation, query and export. Sign or hash critical source snapshots. Validate schemas, permitted predicates and cardinality before promotion. Separate untrusted assertions and quarantine anomalous bulk changes. Back up the vocabulary, graph and provenance store and practise restoration.

The NCSC’s secure AI development guidance recommends inventorying and protecting data, models, prompts and logs, documenting limitations and securing supply chains. The government’s AI Cyber Security Code of Practice provides a further lifecycle baseline.

Governance and operating roles

Name an executive owner for the use case and stewards for each critical entity and vocabulary. Data owners approve use; graph engineers implement schemas and lineage; security and privacy owners approve access; model-risk or assurance teams test retrieval; business users report bad relationships.

Run a change board for vocabulary versions, merge thresholds, new sources and policy rules. Every change needs impact analysis, migration, regression tests and rollback. Publish a data-quality dashboard showing freshness, unresolved conflicts, orphan entities, invalid shapes and provenance coverage.

Measure the business outcome alongside technical quality:

• answer accuracy against an adjudicated question set;
• evidence-link completeness and freshness;
• false entity merges and missed matches;
• invalid relationships blocked at ingestion;
• unauthorised traversal attempts;
• time to resolve a data conflict;
• decision time saved and correction rate;
• percentage of queries returning an explicit uncertainty state.

A measurable 90-day pilot

Days 1–30 — question and foundation. Select one use case, twenty competency questions and two authoritative systems. Define vocabulary, identifiers, provenance, access and retention. Baseline current answer time, corrections and unresolved identities. Complete privacy and threat assessments.

Days 31–60 — controlled graph. Load a bounded historical copy. Validate with SHACL or equivalent rules. Adjudicate entity matches and answer the fixed test set without generation. Add source-level access policies, history and rollback. Attack the graph with conflicts, stale records and poisoned inputs.

Days 61–90 — cited assistant. Let a small user group query the graph through the evidence service. Require citations and capture corrections. Run a supplier outage and restore test. An independent steward samples answers, denied paths and merged entities before expansion.

Proceed only when:

• at least 99% of production assertions have source and effective-date metadata;
• zero high-impact entity merge bypasses the required review;
• every generated factual statement resolves to an authorised graph assertion;
• critical competency questions meet the agreed accuracy threshold;
• access tests prevent prohibited relationship inference;
• schema, vocabulary and model changes are versioned and reversible;
• decision time improves without a higher correction rate.

Pause if source lineage disappears, a graph update cannot be rolled back, protected relationships leak through traversal, draft-standard features create portability risk, or false merges exceed the entity-specific threshold. Stop automated downstream action after an unexplained quality shift. A useful knowledge graph does not merely connect more records; it makes every consequential connection explainable.

Primary sources checked

• Government Data Quality Framework, GOV.UK
• Metadata standards for sharing and publishing data, GOV.UK, updated 22 April 2026
• Data Standards Authority, GOV.UK
• RDF 1.2 Concepts and Abstract Data Model, W3C
• Shapes Constraint Language, W3C Recommendation
• SPARQL 1.2 Query Language, W3C Working Draft, 5 June 2026
• Purpose limitation, ICO
• Secure development of AI systems, NCSC
• AI Cyber Security Code of Practice, DSIT