How TransformRadar uses AI today — drafts from your own data, confirmed by you

"AI-powered" is on every software homepage, including ours. It has become the "new and improved" of enterprise software: technically true, rarely specified, and occasionally attached to a product whose AI is a search box with ambitions.

So this post is the inventory. What the AI in TransformRadar actually does today, what it is not allowed to do, and where it runs. The previous post argued that project tools are becoming systems of action. This one is about the foundations that make that safe, and it is deliberately unexciting, in the way that a good pair of brakes is unexciting.

The rule that shapes everything

TransformRadar's AI reframes your own data. It does not invent.

That sentence is the design rule behind every feature below, and the product is stricter about it than most people are at a dinner party. Every prompt the product sends to a model carries the structured input that licenses every factual claim in the output, and instructs the model to mention nothing outside it. Every output is validated against a schema before a person sees it; raw model text is never rendered. And every AI-produced artefact is a draft a named person owns. Nothing is circulated automatically. Nothing is written to the record without a click from a human who could, in principle, be blamed.

The consequence is that the AI is only as good as the record. That is the point. A steering pack drafted from a live plan, a maintained governance log and a scored health assessment is worth reading. A steering pack drafted from a model's general sense of how programmes go is fan fiction.

What the AI drafts today

Across the workspaces, the AI does one specific job in each, and each job ends in a draft.

• Weekly synthesis. A narrative of what changed on the project this

week — slipped tasks, governance movement, delivery progress — connected into something a steering group member reads in two minutes, on a phone, in a lift.

• Status drafting. The weekly status report's lowlights, activities,

decisions needed, and escalations, filled from the live plan and governance data. The project lead edits every field before submitting, which is where the "actually, that one's fine" gets applied.

• Governance review. A read of the governance log that surfaces what is

stale, unowned, or contradicted by the plan. It is the colleague who asks "is that risk still a risk?" without the eyebrow.

• Value assists. Proposed value drivers from the project's context,

which the lead refines before saving. A starting point instead of a blank form and a sigh.

• Steering narratives. The pre-meeting pack's sections, summarising what

moved since the last steering meeting across status, health, governance, plan, delivery, and value.

• Project context briefs. A lead-curated brief that grounds every other

prompt, so the model knows what this programme is for before it drafts anything about it. Models, like new joiners, do better with an induction.

Blip: ask the project, or ask it to prepare a change

Blip is the assistant inside every project workspace and on My work. It answers from the live record: what is overdue, what changed in delivery, which risks are open without an owner. It reads the same data the screens show and nothing else. It has no opinions about your programme that it did not get from your programme.

Blip can also prepare a change. Ask it to log a risk, create a task or a delivery item, or update a status draft, and it prepares the change and shows you a confirmation card: what will be written, and what it looked like before. You approve, or you do not. Blip never commits a change on its own; the confirmation belongs to the product interface, not to the model. And Blip acts strictly as you, inside your own permissions on the project. It cannot see a project you cannot see, or change a thing you could not change by hand. It is you, with better recall and no lunch break.

MCP: bring your own agent

The Model Context Protocol lets an external AI client connect to a platform and use its capabilities. TransformRadar is an MCP server. An organisation's admin can switch on external access, choose which clients are allowed (Claude, ChatGPT, Cursor, Google Gemini, and Mistral Vibe today), and each user connects with a standard sign-in.

The connected agent then acts as that user, with that user's project roles, through exactly the same governed actions the buttons in the product use. Reads come with access: projects, the plan, the delivery backlog, the governance log, status reports, steering plans, value, and Programme Health. Writes are switched on separately, in tiers, and every write follows the same preview-then-confirm protocol as Blip. The agent receives a preview. A person confirms. The agent does not get to be disappointed.

This is the piece that matters most for the agentic era. It means the governance record is available to whatever agent your organisation already uses, on the same terms as a human user, without a second permission model bolted on for AI and forgotten about.

One action layer, no privileged path

Behind Blip and the MCP surface sits a single action layer: every operation an AI can reach is a registered capability with a schema, a permission check, a minimum project role, and an audit event. Blip, an external agent, and a button in the interface are all clients of the same layer. AI never gets a route to data or to a mutation that the interface does not have. There is no back door, not even a nice one.

Every mutation records which surface made it, so an audit trail can show that a risk was created through Blip, confirmed by a named person, at a given time. Every AI call is logged with who triggered it and which artefact it relates to; the payloads are kept for thirty days for review and then removed.

Where it runs

Inference runs on Mistral's platform in Paris. That is a choice about the whole chain, not a region setting: hosting and the database, object storage, email, and AI inference are all European providers, and none of them trains on customer data. The EU hosting page has the full account for the day procurement sends the questionnaire.

The one sanctioned exception is MCP. When you connect your own agent, that agent's provider handles the conversation, which is why an Org Admin has to acknowledge the egress before switching external access on. The record stays where it is. What leaves is what the agent asks for, on that user's behalf.

If the AI provider is slow or down, features degrade to a deterministic summary or an empty state. A broken page is not an acceptable failure mode for a steering pack, and "the AI is down" is not an acceptable reason for one.

What this is not yet

TransformRadar's AI today is synthesis and preparation. It reads, it drafts, it proposes. It does not chase task owners, it does not watch the record continuously and raise anomalies on its own, and it does not negotiate with other systems' agents. Those are the next steps, and the next post is about them. What will not change is the rule at the top of this one: it reframes your data, it never invents, and a person confirms.

• AI
• Blip
• MCP
• governance
• product