PRIMARY-SOURCE RESEARCH MAP · VERSION 1 · 1 OCTOBER 2026

From impressive demo to accountable system

AI & Big Data Expo Europe supplies the technical lens for The 100: not whether AI can produce an answer, but how a real system earns permission to act, survives failure, shows its evidence and proves its value.

When: 19–20 October 2026
Where: RAI Amsterdam
Official programme: 6 AI/Big Data stages + Physical AI + adjacent TechEx tracks
RN purpose: A reproducibility and accountability standard for 100 builds

What the programme is really about

The verified programme repeatedly returns to one engineering problem: the model is no longer the hardest part. The frontier is the surrounding system—data, identity, authority, memory, orchestration, evaluation, infrastructure, governance, human review and value measurement.

Day 1 · AI Leadership

Autonomous-agent foundations, research validation, token economics, network constraints, responsible evaluation and agentic data architecture.

Day 1 · Enterprise AI

Data products, operating models, coding agents for high-risk pipelines, master data and governed software-production skills.

Day 1 · AI Builders

Converging platforms, full-traffic observability claims, delegated authority and build/buy/combine strategy.

Day 2 · Data & Analytics

Production durability, agent identity through MCP, build-versus-buy, lock-in, IP ownership and attributable ROI.

Day 2 · Future AI

Legal-risk-engineering alignment, monitoring and audit trails, agentic operating models and skepticism about benchmarks.

Day 2 · AI Developer

AI coding, identity-aware memory, context engineering, RAG, orchestration, evaluation, MCP and self-hosted small models.

Interpretation: this synthesis is RN’s inference from the official agenda. It is not an official characterization by the event.

RANKED TECHNICAL FRONTIER MAP

Twelve questions every serious build must answer

Production agents need bounded authority

Verified programme evidence: AI Builders introduces the 5 A’s: Authority, Access, Approval, Accountability and Adaptation. Data & Analytics adds identity-provider controls for MCP-connected agents.

Why it matters: An agent is not “safe” because its prompt says to behave. Its permissions, approvals, owner, stop control and audit trail must exist in the system.

Ask of every RN build: For every action: what may the agent decide, which tool or record may it touch, who approves, who is responsible, and how is access revoked?

The product is the whole system around the model

Verified programme evidence: Ford Credit’s developer session frames production AI as distributed software: orchestration, context engineering, evaluation, memory, observability and governance.

Why it matters: A model call is one component. Reliability depends on everything before it, around it and after it.

Ask of every RN build: Draw the request path from user input through validation, retrieval, model, tools, storage, review and final output. Name every boundary.

Memory must know who and what it describes

Verified programme evidence: The AI Developer programme includes an identity-aware memory layer using entity resolution for a Fortune 500 insurer.

Why it matters: Saving conversation text is not enough. The system must distinguish people, organizations, records, sessions and permissions without merging the wrong entities.

Ask of every RN build: What is remembered, under which identity, for how long, in which store, with what retrieval rule, and how can it be corrected or deleted?

Evaluation must run continuously

Verified programme evidence: BBC addresses responsible evaluation at scale; Future AI specifies monitoring, logging and audit trails; Splunk claims evaluation of all agent traffic with real-time blocking.

Why it matters: A one-time demo cannot prove a system is dependable. Tests must measure quality, safety, task success, regressions, latency and cost over time.

Ask of every RN build: State the test set, metric, threshold, failure response, reviewer, sampling rate and evidence retained for each important behavior.

Data architecture determines agent quality

Verified programme evidence: IBM links real-time access, security, governance, trust, silos and lineage to agentic scale. Shell, Volvo, Eneco and IBM discuss data products and product ownership.

Why it matters: Agents cannot repair undocumented, inaccessible or contradictory data by sounding confident.

Ask of every RN build: Name each source, owner, schema, refresh cycle, transformation, quality check, lineage record and rule for resolving conflicts.

Open and self-hosted models are an operating choice

Verified programme evidence: GLS reports a multi-country customer-service system built with self-hosted open-source small language models, with guardrails, scale, accuracy, regulation and predictable cost as explicit concerns.

Why it matters: “Which model is best?” is the wrong first question. Control, data location, latency, skill coverage, maintenance and total cost determine the right deployment.

Ask of every RN build: Explain why this model and hosting mode were chosen; compare privacy, control, quality, latency, lock-in, maintenance and per-task cost against alternatives.

Infrastructure and token economics are product constraints

Verified programme evidence: AI Leadership covers finance-grade ROI, token economics, latency, jitter, cross-cloud data movement, network sovereignty and the cost of agentic data architecture.

Why it matters: An architecture that works only when cost and latency are ignored is not production-ready.

Ask of every RN build: Provide token, compute, storage, network and human-review costs per task; include latency targets, limits, caching, retries and graceful degradation.

Build-versus-buy is about ownership over time

Verified programme evidence: Data & Analytics explicitly weighs vendor lock-in, IP ownership and long-term costs; AI Builders warns against vendor sprawl, over-engineering and technical debt.

Why it matters: A fast vendor integration may become an expensive dependency. A custom system may create maintenance work the team cannot sustain.

Ask of every RN build: List what is owned, rented and replaceable; document export paths, switching costs, proprietary dependencies and the smallest viable internal capability.

AI-assisted development moves the bottleneck to review

Verified programme evidence: Datadog describes coding agents for data pipelines where bad code may run successfully and poison downstream data. In The Pocket describes 400 governed production skills across its software lifecycle.

Why it matters: Faster generation increases the volume that needs verification. Quality systems must scale with output speed.

Ask of every RN build: Show generated versus human-authored work, automated checks, reviewer responsibility, release gates, rollback and how silent data errors are detected.

Human trust requires measurable trustworthiness

Verified programme evidence: Future AI challenges benchmark overfitting and the human tendency to project intention onto fluent systems; its risk-stack panel asks for classification, controls, monitoring and auditability.

Why it matters: Friendly language and impressive benchmarks are not evidence that a system understands, is correct or should be trusted.

Ask of every RN build: Separate observed performance from marketing claims and inference. Show limitations, uncertainty, known failure modes and the evidence a user can inspect.

Physical AI closes the loop with the world

Verified programme evidence: The official programme includes a dedicated Physical AI track and co-located edge, IoT and intelligent-automation tracks covering robotics, autonomous systems and industrial operations.

Why it matters: When software senses or changes the physical world, timing, safety, device failure and human override become part of the architecture.

Ask of every RN build: For any physical input or action, specify sensor, sampling, edge/cloud split, control loop, safe state, override, environmental limits and recovery.

Value must be attributable, not merely asserted

Verified programme evidence: Leadership and Data & Analytics sessions question activity metrics, reported productivity gains and AI budgets whose costs are visible but value is not.

Why it matters: Usage, outputs and speed do not prove that a build helped. A causal story and an accountable measurement plan are required.

Ask of every RN build: Define the baseline, intended outcome, owner, counterfactual, measurement window, confounders and rule for stopping or redesigning the system.

THE RN BUILD EXPLANATION CONTRACT

CTO-complete. Twelve-year-old clear.

Every case study must contain all twenty records below. “Connect the API,” “add a database,” “use an agent” and “apply safeguards” fail this standard. The explanation must identify the exact component, input, output, decision rule, failure behavior and visible proof that it worked.

Record	Plain question	Minimum proof
1. Provocation	What happened that made this worth building?	Name the person or institution affected, the existing failure and the evidence that it is real.
2. Promise	What can the finished system actually do?	Use testable verbs. Separate live capability, prototype, simulation and planned work.
3. Boundary	What does it deliberately not do?	State non-goals, prohibited uses, unsupported users, jurisdictions and decisions reserved for people.
4. Journey	What does a person do from start to finish?	Number every screen, choice, input, wait, correction, output and next step.
5. System map	Which parts talk to which other parts?	Name the browser, server, model, agent, database, queue, API, file store and third-party service; label every connection.
6. Data contract	What enters, changes, persists and leaves?	For every field give its type, source, validation, transformation, destination, retention and deletion rule.
7. Intelligence split	Which work is deterministic and which uses AI?	For each step name rule, search, model or human judgment; explain why uncertainty is acceptable there.
8. Agent contract	What may each agent perceive, decide and change?	List tools, credentials, scopes, approvals, budget, stop condition, escalation route and accountable human.
9. Context and memory	How does the system know what matters now and later?	Document retrieval query, context assembly, identity resolution, memory write/read/delete rules and contamination defenses.
10. Model decision	Why this model, size and host?	Compare quality, privacy, latency, control, availability, regulation, lock-in and total cost.
11. Failure tree	How can it fail, and what happens next?	Cover bad input, missing data, timeouts, rate limits, model error, tool error, stale state, unauthorized action and partial completion.
12. Assurance	How do we know it works and remains safe?	Name test cases, metrics, thresholds, adversarial tests, monitoring, alerts, audit logs and regression cadence.
13. Security and rights	Who may access, copy, change or remove what?	Explain authentication, authorization, secrets, encryption, provenance, license, privacy, consent and incident response.
14. Operations	What does production require every day?	Include deploy, environments, configuration, observability, support, backups, rollback, capacity, latency and cost ceilings.
15. Reproduction	Could a determined twelve-year-old rebuild the logic?	List prerequisites and exact steps in order. Define every term at first use and include a visible pass/fail check after each step.
16. Design rationale	Why is the experience shaped this way?	Connect information order, interface, typography, imagery, friction and feedback to a human need—not aesthetic preference alone.
17. Decision history	What was tried, rejected and changed?	Show hypothesis, experiment, failure evidence, correction and the commit or artifact proving the change.
18. Evidence ledger	Which statements are facts, claims or inference?	Attach a source, date and scope to facts; label vendor claims and RN interpretations; never blend them.
19. Value test	What outcome would justify keeping it?	Define baseline, target, measurement period, cost, owner and the evidence that would trigger shutdown or revision.
20. Exhibition label	What must a cold reader know in thirty seconds?	Build number, purpose, status, stack, date, author, live link, repository, sources, rights, limitations and next experiment.

One traceable sentence at a time

Verified fact

Directly supported by code, logs, tests, a deployed interface, an official source or a preserved artifact. Attach source, date and scope.

External claim

A speaker, vendor or institution says it. Name the claimant and do not silently convert the statement into independent fact.

RN inference

A reasoned interpretation connecting evidence. Show the evidence chain and state what could disprove it.

Unknown

Evidence is absent, incomplete or not yet inspected. Record the gap and the exact action needed to resolve it.

Questions to bring into the room

Show the diagram you use internally when this fails—not the polished architecture diagram.
What decision can the agent make today that it could not make six months ago, and who gave it that authority?
Which evaluation catches the most expensive failure? Which failure still has no reliable test?
What does one successful task cost after tokens, infrastructure, human review and rework?
Where can a user see the source, uncertainty and action log before trusting the result?
What changes when the same system serves a child, employee, customer, regulator or person in crisis?
Which dependency would be hardest to replace, and what evidence would make you replace it?
What is the system allowed to remember? How does a person correct or erase that memory?
What claim in this presentation is measured, what is inferred and what is still aspirational?
If network access, a model provider or one database fails, what remains useful and safe?

Claims and tensions to test

Autonomy vs. control

The programme promotes agents that plan and act while also demanding narrow authority, approvals, traceability and human accountability. Ask where autonomy actually begins and ends.

Speed vs. durability

Vendors promise weeks-to-deployment while speakers warn that rushed architectures create cleanup, drift, technical debt and unsafe access. Ask what was omitted to achieve speed.

Democratization vs. review burden

Coding agents lower barriers, but generated pipelines can quietly corrupt downstream data. Ask whether review capacity grew as quickly as generation.

Open control vs. maintenance cost

Self-hosting can improve sovereignty and predictability while transferring security, upgrades, evaluation and operations to the adopter. Ask for total—not token-only—cost.

Benchmark performance vs. real usefulness

A model can score well, speak fluently and still fail a specific workflow. Ask for task-level evaluation with real users, failures and counterfactuals.

Visible usage vs. provable value

Activity and productivity estimates are easy to report. Attribution, avoided harm and durable outcome improvement are harder. Ask what evidence finance would accept.

HONEST COVERAGE BOUNDARY

What this research cannot yet prove

The agenda is still changing. Several 2026 slots are marked TBC and some speaker profile pages do not yet carry session details.
Session descriptions are proposals, not published proceedings. Claims about scale, ROI, safety or performance remain unverified until speakers provide evidence.
The official site identifies more than 200 exhibitors across eight co-located events, but exhibitor descriptions are self-authored marketing copy and not an independent capability audit.
The public agenda does not yet expose slide decks, implementation repositories, model cards, evaluation datasets, cost tables or post-event recordings.
Physical AI, Founders & Future, Learning Hub and co-located tracks live on separate sites. This page maps their relevance but does not pretend every future programme change has already been captured.
A complete RN-build crosswalk requires repository-by-repository reconstruction. No build should be assigned a frontier merely because its title sounds related.

Official source register

All event facts on this page were checked against the organizer’s current public pages on 1 October 2026. Agenda details may change before the event.