The day begins on a shared stage rather than with a single keynote, where several leaders introduce ideas that follow throughout the day.

It opens with the question the Forum exists to ask. Trustworthy AI sits at the intersection of engineering best practice, legal regulation, and human ethics. Most of the day is spent on the first two, but almost everyone building AI today is asking one of three questions: How do we build it, how do we exploit it, how do we control it? Far fewer ask what kind of organizations we intend to build with this technology, and an organization that cannot answer that has no way to judge which AI is worth the investment.

From there the morning turns practical. A live look at what changes when AI strategy and architecture stops being a document and becomes an instrument you can use, a featured keynote from the Chief of Information Management at UN Political and Peacebuilding Affairs, and an introduction to AI diligence, a discipline most leaders are already subject to without having named it.

What attendees leave with: a common vocabulary for the day, a higher bar for what counts as a hard problem, 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.

AI-specific diligence frameworks are now published and in active use. The question for any organization is no longer what will be asked, but whether it can answer.

This symposium covers what serious questioners now demand across proprietary development, third-party AI, deployment and controls, training data and governance, and generative outputs. In a transaction, those answers move valuation, deal structure, risk allocation, and post-close remediation budgets, and that case is examined properly. But the transaction is only the most concentrated form of a pressure that is now continuous and largely indifferent to sector. Enterprise customers send AI questionnaires in major procurements. Insurers are beginning to underwrite AI posture. Boards and governing bodies carry fiduciary exposure. Donors, member states, oversight offices, and auditors ask the same questions on different letterhead. And every organization that buys or partners its way into AI capability is performing diligence rather than receiving it, usually without a framework for doing so.

Two findings transfer everywhere. The absence of evidence is itself a finding, and interviews with technical teams reveal more than document review ever will. Which leads to the central argument: everything a serious questioner asks for is either an artifact a well-run AI program already produces, or evidence that no such program exists. Readiness in steady state turns out to be indistinguishable from running the thing properly.

What attendees leave with: the questions their organization will be asked, an honest read on which of them they can answer today with evidence rather than assertion, and a usable structure for the questions they should be asking their own vendors and partners.

Neither a market forecast nor a vendor's view of the world. This is what has actually been observed leading this work with organizations across more than fifteen countries and six sectors: where the money is going, where it is being wasted, which capabilities reliably separate the organizations pulling ahead, and how the picture differs by region and by sector. It draws on maturity assessments run against five pillars and twenty-five dimensions, so the patterns are measured rather than anecdotal.

Expect some uncomfortable findings, among them the averaged-score trap, where visible strength in a few dimensions conceals weakness in the ones carrying real weight. And expect the aggregate answer, which is that nearly every organization in the world still sits somewhere between reactive and proactive, whatever its press releases say.

What attendees leave with: a candid benchmark against peer organizations, and a sharper sense of which current investments are load-bearing.

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 Human Context Protocol 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.

Building agents is no longer the hard part. The hard part is the decision to let one loose in the business, with real permissions, real money, and real customers on the other side of it. Many organizations stall at exactly that point, and they stall in similar ways. Every new agent requires senior people to reason from first principles about what it might do, who it could harm, and what happens if it is wrong. There is a hard limit on how many times a leadership team can hold that conversation, and most find it early. Which is why so many organizations that can demonstrate something remarkable can name only a handful of agents actually running.

The symposium begins from an observation that lands badly and is true. A rule written in a document cannot stop anything. It can shape how a system gets built, and a well-written one is genuinely valuable at design time, but at the moment an agent acts, something inside the running system has to allow it, refuse it, or hand the decision back to a person. We walk through what changes when an agent leaves a supervised pilot, and why testing and control are two different problems requiring two different answers. Testing tells you how a system behaved on the cases someone thought to write down. Runtime control determines what happens on the case nobody anticipated, at three in the morning, when the agent holds credentials. Expect specifics: what it means to express a rule as something a system enforces rather than something a person reads, where those checkpoints sit, what a deterministic answer looks like inside a non-deterministic system, and what should happen when the check itself fails.

The argument is about velocity rather than caution. The constraint on your AI portfolio next year will not be model capability and probably will not be budget. It will be how many things you are able to allow. Organizations that have made the approval decision reusable can say yes in an afternoon. The rest go on saying it in quarters. The same machinery, incidentally, produces a defensible answer for a board, an auditor, an insurer, or a regulator, which is a good deal of value from a decision made on commercial grounds.

What attendees leave with: a specific list of what to require before approving an agent for production, a way to tell how much of it their existing platform already provides, and a straight answer for their next board meeting.

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.

Microsoft's Director of Enterprise AI Advocacy closes the day on what she sees inside organizations: the ones that make the leap, the ones that stall, and the difference between them, which is rarely what leadership believes it is.

The second half is ask and answer. Put your real problem to the room, whatever the day has surfaced or failed to resolve. Often the answer turns out to be someone three seats away who solved it eighteen months ago, and those introductions are made deliberately and followed up after the event rather than left to the coffee queue. It is the part of the day the Forum takes most seriously. Published knowledge is durable, but a peer who will take your call next year is worth more.

What attendees leave with: a straight answer from someone who sees hundreds of these programs, at least one introduction worth having, and a next step that fits their organization.