The day opens on the ground upon which the Forum stands. Trustworthy AI sits at the intersection of engineering best practice, legal regulation, and human ethics, and the leaders in this room need all three to lead well.

Andrew Welch then shares a view from around the world, drawn from leading AI strategy work with organizations in more than fifteen countries. It begins with what those organizations say they want. Five aspirations recur almost everywhere: a sustainable foundation free of brittle dependencies and costly sprawl, data put to work as a strategic capability, people enabled for the Age of AI, strategic discipline and trust, and real problems solved in production and tied to mission outcomes. Weigh them against each other, and one stands out, which is that changing how the organization works matters more than changing what it buys.

The picture is measured rather than anecdotal: five pillars, twenty-five dimensions, and five levels of maturity running from Unaware to Strategic. The aggregate answer is uncomfortable. Nearly every organization sat between reactive and proactive a year ago, and nearly every organization still does, whatever its press releases say. AI strategy is what moves an organization along that curve, but only once the model becomes an instrument.

That sets up a live look at Centru.ai, launched last week in London, which turns AI strategy and its execution from a document into something an organization can use. Dona Sarkar, Microsoft's Director of Enterprise AI Advocacy, delivers the featured keynote, followed by a short keynote from Mike Bugembe, Chief Digital Officer at the International Organization for Migration. Andrew closes the session with the shape of the day before the room releases to the working sessions and symposia.

What attendees leave with: a candid benchmark against organizations around the world, a sharper sense of which current investments are load-bearing, and a question about their own organization they did not arrive with.

Working Session A. Runs alongside the symposia. Attend both working sessions, one, or neither.

Building an agent is no longer the hard part. Keeping a population of them running inside a real organization is. This session takes on the machinery that decides whether agents survive contact with the organization's real work, and it stays deliberately platform-neutral: identity and permissions, ownership and who gets called at night, cost and consumption, observability, versioning and change control, retirement, and the problem of the agents nobody registered.

It is work rather than talk. Attendees put their own blockers on the table at the start, the group sorts them into the patterns that keep recurring, and the remainder of the time is spent building shared answers to the ones most of the room holds in common. The conversation stays at the level where it transfers, so that a bank or a public sector agency can use a version of the same answer, with each participant's specifics as the worked examples.

Nothing needs to be written on the day. The work is captured and, in the weeks that follow, published as a reference with every contributor credited as a co-author unless they prefer otherwise.

What attendees leave with: their hardest production problems worked through by a room of peers, the contacts of everyone who worked on them, and their names on the published result.

Most of the conversation about trustworthy AI is a conversation about safety. This symposium argues that trust also depends on whom a system works for, and whom it quietly fails. It is built around four ideas.

Representation before deployment. Trust starts with knowing who is represented in the data, who is missing, and which populations may experience systematically different outcomes.

Disaggregated evaluation. Aggregate performance can conceal failure. AI systems should be tested across age, gender, language, geography, accessibility, and other relevant user contexts before deployment.

Institutional capability to detect exclusion. Inclusion cannot be an end-stage review. Product, policy, data, and operational teams need practical methods to identify representation gaps throughout the AI lifecycle.

Shared infrastructure for inclusive AI. Organizations should not have to reinvent these methods independently. Shared benchmarks, testing frameworks, datasets, and evaluation tools can make inclusion repeatable and scalable.

What attendees leave with: a set of questions to put to any AI system before it is deployed about who it was built and tested for, a sense of where in their own lifecycle exclusion is most likely to go unnoticed, and a view of which tools they need not build alone.

Sooner or later, someone who does not know your organization, is not inclined to trust it, and is under no obligation to be fair will ask it to prove how its AI works. AI-specific diligence frameworks are now published and in active use, among them the framework from Danny Tobey and colleagues at DLA Piper that this work takes as its starting point. The question is no longer what will be asked. It is whether the answer exists before the question arrives.

This symposium is the technologist's companion to that legal framework, drawn from original work published by the Center for Trustworthy AI. It walks the demand areas a serious questioner now covers — proprietary development, third-party AI, deployment and controls, training data and provenance, generative outputs — and then makes the argument that matters more than any checklist. Everything counsel asks for is either an artifact a well-run AI program already produces, or evidence that no such program exists. Diligence is a maturity assessment performed by strangers, under time pressure, with valuation at stake. The organization does not set the questions, choose the assessor, or pick the week.

The findings carry further than the transaction. Materiality inverts: what engineers treat as routine turns out to move price, and what keeps them up at night often does not. Documentation is an asset rather than an obligation, and its value collapses the moment it is assembled under deadline. Most AI now sits somewhere between bought and built, which is precisely where the hard questions live. And readiness cannot be manufactured once the clock has started. The session takes all three positions an organization can occupy — a live transaction, one on the horizon, and steady state, where most of the room sits today — because this pressure is no longer confined to M&A. Enterprise customers send AI questionnaires in major procurements, insurers are beginning to underwrite AI posture, and donors, auditors, and oversight offices ask the same questions on different letterhead. Most organizations will conduct this diligence more often than they undergo it. Readiness in steady state turns out to be indistinguishable from running the thing properly. This is not legal advice, and it is not a lawyer's reading of the law.

What attendees leave with: the demand areas their organization will be asked about, a way to tell whether they could answer each of them with evidence rather than assertion, and a usable structure for the questions they should be putting to their own vendors and partners.

Working Session B. Runs alongside the symposia. Attend both working sessions, one, or neither.

Every organization runs on context its people hold implicitly. Who decides what. What gets escalated, to whom, and how fast. What good work looks like. What is never done regardless of who asks. Almost none of it is written down, and agents inherit none of it. The AI Workforce of the Future is an open line of work on making that context explicit enough that mixed teams of people and agents can operate against it: leadership capabilities, decision rights, and the operating norms of teams whose members are not all human.

This is a drafting session. What is a role when part of it is performed by an agent? Where does accountability sit when the work was assembled by software and approved by a person? What must digital fluency mean now? What do regulators already expect an organization to demonstrate about the competence of its people? The work stays at the level of the protocol rather than any one sector, with participants' own situations as the test cases.

Contributions are captured and developed after the event into a published set of protocol components, distributed to everyone present, with contributors credited as co-authors unless they prefer otherwise.

What attendees leave with: a first draft for their own organization, a set of questions their leadership team has not yet been asked, and their name on the published work.

AI agents are increasingly entrusted with complex tasks, sensitive data, and real-world actions...but most teams still evaluate and govern them using disconnected tools, generic benchmarks, and controls tied to a single platform or framework.

In this talk, we introduce two open-source tools: ASSERT and the Agent Control Specification (ACS).

• ASSERT turns natural-language requirements )what an agent should and should not do) into executable, scenario-specific evaluations. It helps developers systematically generate tests, evaluate multi-turn agent behavior, identify failure modes, and produce evidence grounded in the agent’s intended purpose rather than generic benchmark scores.

• ACS carries those requirements into production. It provides an open specification for attaching policies to critical intervention points across an agent’s execution, including user input, model interaction, tool calls, and final output. This enables policy engines, classifiers, deterministic rules, and LLM-based judges to produce normalized decisions that agent platforms can consistently enforce.

Together, ASSERT and ACS establish a continuous governance loop: define intended behavior, evaluate whether the agent satisfies it, discover new risks through testing and red teaming, translate findings into runtime policies, and continuously strengthen those policies using production evidence. Attendees will learn how specification-driven evaluation and portable runtime controls can make governance part of the agent development lifecycle, without locking developers into a particular model, framework, or deployment platform.

The session opens with a diagnosis drawn from decades of work inside operationally complex, heavily regulated businesses. Eight symptoms, found in almost every estate. A new product needs a code release. The people who own the pricing cannot change the pricing. Work arrives as documents and leaves as typing. Six systems hold three answers to the same question. Nobody can say who changed a record, or whether they were allowed to. Twenty years of customization nobody will touch. Every partner wants something different, and none of it ever retires. The examples come from insurance. Every symptom is a property of how systems are arranged rather than how the business is run, and all of them share one cause. When systems cannot talk to each other, the business rules, the integration logic, and the reporting end up duplicated inside each of them. Substitute your own eight.

What follows is an argument about what happens when agents arrive on top of that estate. An agent that wants to act has to ask whether it may, and the question is unanswerable unless one place knows the entities, their relationships, and the authority rules on them, and one point enforces authorization, orchestration, and an immutable record of every call. Some things have to be the same every time. Systems of record can vary, the surfaces people work on can vary, and the models certainly will. The domain model and the gateway cannot. This session presents an architecture built on that principle, including the deliberate decision that audit logging and integration are not components anyone gets to select, because they are how everything else is reached.

The session closes on two questions senior leaders are already asking. Where the human decision should sit once software does the assembly and the person does the deciding, and which number to fix first, so that the next one costs less to fix than it otherwise would.

What attendees leave with: their own version of the eight symptoms, a clear test for what in their estate must be the same every time, and a sequencing argument they can take into a budget conversation.

Avishan Bodjnoud, Chief of Information Management for the United Nations Departments of Political and Peacebuilding Affairs and Peace Operations, delivers the closing keynote, drawing on what she sees from inside an organization whose work matters deeply to people around the world.

Andrew Welch then closes the Forum. The introductions made across the day are followed up deliberately after the event rather than left to the coffee queue. Published knowledge is durable, but a peer who will take your call next year is worth more.

What attendees leave with: a perspective from the front line of AI in the United Nations system, at least one introduction worth having, and a next step that fits their organization.