When a health system runs AI intake on a platform, vendors fill in fields

A governance platform turns AI intake from a conversation into a record with required fields. Trustible announced on Oct. 28 that Mass General Brigham has begun implementing its platform to structure and track the intake of proposed AI use cases, support risk assessment and tiering, route requests for review, document decisions, and keep a central inventory of reviewed and approved use cases. For a vendor, that changes the shape of the first ask. Instead of a questionnaire you answer in prose, expect a form that maps your answers to a risk score.

Two cautions before going further. The source is Trustible's own announcement, so this is the vendor's description of the work. And the release itself says the agreement does not constitute an endorsement of Trustible or its products. I am not claiming to know what Mass General Brigham's intake form contains. What follows is my expectation of what a platform like this will ask, based on what the release says the platform does.

What the announcement actually says

According to Trustible, the platform supports Mass General Brigham's existing AI governance process and responsible use framework for use cases across clinical, research, and operational settings. It is a tool for a process the health system already runs, not a replacement for its judgment. Mass General Brigham's chief health information officer, Rebecca Mishuris, MD, is quoted in the release saying technology can support the process while experienced AI leaders interpret risk and make informed governance decisions.

Trustible describes a model where each use case has one record that follows it from intake through risk assessment, approval, compliance mapping, and monitoring. Risk scoring draws on factual attributes of the use case, such as the data involved and the population affected, and reviewers can accept or override a score with a documented rationale. Control mappings let a team document a practice once and apply it across CHAI guidance, the NIST AI RMF, ISO/IEC 42001, and other frameworks.

Some of the work is exploratory. The release says the two organizations will explore a more automated, repeatable method for evaluating AI vendors and use cases, both before approval and as vendors change their products, and will examine which post-deployment signals matter, who owns each metric, and what thresholds should send a use case back for review. I read that as direction, not a finished program.

Why a platform changes the vendor's job

Last month I wrote about CHAI's draft intake controls and argued for building one evidence package you reuse across health systems. A platform makes that advice sharper, for three reasons.

Attributes drive the score. If risk tiering is computed from facts about the use case, the facts you supply decide how much review you get. Vague answers do not get you a lighter review. They get you a follow-up, or a conservative default.

The record persists. One record from intake through monitoring means your intake answers are still on file when someone checks the use case later. If your product changes and the record does not, that gap is visible.

Mappings reward reuse. If a practice documented once can map across CHAI guidance, NIST AI RMF, and ISO/IEC 42001, a vendor that already writes evidence against those frameworks has less to translate.

The fields I expect to be asked for

This is my list, not Mass General Brigham's form. I built it from the functions the release names: intake, attribute-based risk scoring, review routing, decision records, inventory, and monitoring.

1. Use case description. What the tool does, in which setting (clinical, research, or operational), and who uses the output. Write one entry per use case, not one per product.
2. Data involved. What data the tool reads and writes, whether it includes PHI, and where it is processed and stored.
3. Population affected. Which patients or staff the output touches, and whether the tool was validated on a comparable population.
4. Autonomy and human role. Whether a person reviews every output, samples them, or the tool acts on its own, and what that person is expected to check.
5. Model and change process. What kind of model runs underneath, who supplies it, and how you notify the health system when you change the model, the prompt, or the training data. The release names evaluation as vendors change their products, so expect this one.
6. Performance evidence. What you measured, on what data, and the known limits.
7. Framework mappings. Where your existing documentation lines up with CHAI guidance, NIST AI RMF, or ISO/IEC 42001.
8. Monitoring signals. What the health system can watch after go-live, which signals you provide, who on your side owns them, and what level should trigger a second look.
9. Owners and contacts. A named technical contact for review questions and a named owner for each monitoring signal.

How to have them ready

Write each field as a short factual answer, with a link to the evidence behind it. Keep the answers in one document you version, so when the product changes you update the record and tell the health system, instead of waiting for them to find the drift.

Pay the most attention to fields four, five, and eight. Autonomy and population are the attributes most likely to move a risk tier. Change notification and monitoring are where the release says the work is still being defined, which means the vendors who show up with a clear answer help set the expectation.

If a reviewer overrides your risk score, ask for the documented rationale the release says reviewers record. It tells you exactly what to fix for the next health system.

The next intake you face

Take your most clinical use case and fill in the nine fields above today, in plain sentences, each with a link to evidence. Count the fields where you had to write "we will get back to you." That count is the review delay you have already scheduled for yourself. Which field took you longest?