# The AI vendors you rely on, and which nobody assessed.

> Third-party AI risk in ColossalX starts from the AI vendors you actually use, found from your gateway providers and your app catalogue, not from a list someone typed. Each is labelled assessed, in use but not assessed, record only or self-hosted, and the risk register can be sent out to your GRC, ticketing and third-party risk tools.

ColossalX finds the AI vendors in real use, flags the unassessed ones and sends the register to the tools you already run.

Canonical page: https://colossalx.tech/platform/third-party-ai-risk · Last reviewed: 7 Oct 2026

*Illustration:* Questions · each ends in a record: Which AI vendors do we use? ends in Listed from real use; Which of them did nobody assess? ends in Flagged: in use, unassessed; Where does the register go? ends in Signed, outbound only.

## The threat and the control

- **The threat:** A team starts using an AI vendor, and nobody ever assesses it.
- **The control:** ColossalX builds the vendor list from real use and flags the vendors nobody has assessed.

## How it works: From real AI use to a flagged vendor.

One AI vendor in real use, followed from the gateway and the catalogue to a flag, an assessment and a register sent out.

### Workflow: an AI vendor nobody assessed, then registered (illustrative)

1. **Provider configured.** A team's AI provider is configured on the gateway.
   provider A · Configured on the gateway · In use | Source: Gateway providers; Team: Support
2. **Laid against register.** The inventory is laid against your register and catalogue.
   Provider A: No assessment on file; Register: Not listed | In use, not assessed
3. **Added to register.** A person adds it to the register, and the label changes.
   Risk analyst: Adds provider A, with a risk tier | Assessed
4. **Register sent out.** The risk register is sent on to your GRC tool.
   Destination: GRC tool, signed webhook; Direction: Outbound only | Delivered · Replayable | x, accounted for

## What you see: Which vendors are in use, and which are assessed.

The inventory lays real use against your register and labels each vendor. A source that could not be read says so.

1. **Find vendors in use.** Vendors come from your gateway providers and your app catalogue. The inventory is built from the systems of record, not from the register: the AI providers configured on your gateway and the apps in your AI app catalogue. When a discovery scan runs, more vendors can appear. If a source cannot be read, the panel says the list is shorter than the estate, not smaller.
2. **Label each one.** Each vendor reads assessed, in use but unassessed, or record only. The labels are Assessed; In use, not assessed; Record only, where it is assessed but nothing shows it in use; and Self-hosted, where no third party is involved. A count of unassessed vendors sits with them, so the gap is a number to close, not a feeling.
3. **Keep a register.** Record a vendor by hand: category, risk tier and last assessment. The register is a manual list: add a vendor with its category and risk tier, and see its contract expiry and last assessed date. It is a record, not a questionnaire workflow, and ColossalX does not send vendor questionnaires. The risk overview counts vendors tracked and reviews overdue.
4. **Send it out.** Risk Sync sends the register to your GRC and ticketing tools. Add a destination: a signed webhook, or a route to your ticketing connection that opens a ticket for each new or critical risk. Choose the events and a minimum severity. Deliveries are signed, retried and replayable, and the sync is outbound only: nothing is pulled back, so a tool outside cannot change the register.

*Illustration:* An illustrative vendor inventory: three generic AI providers and a local runtime in use, each labelled assessed, in use but not assessed, record only or self-hosted, with the gateway and app catalogue they were built from and a signed, outbound-only risk sync beside them. Notes: 1. In use, but nobody assessed it 2. Built from real use, not a typed list 3. Signed, and outbound only

## How we know

- Vendors come from gateway providers and the app catalogue, not only from the register.
- A source that cannot be read is named, so a short list is not mistaken for a complete one.
- Risk Sync is signed, replayable and outbound only; nothing is written back to the register.
- A self-hosted model is labelled as such, because no third party is involved.

## Where a vendor finding goes next.

The inventory reads from your gateway and catalogue, and what it finds reaches the risk register.

- **The AI gateway.** Providers configured on the gateway are the first source of vendors.
- **Shadow AI.** A discovery scan can surface vendors nobody configured.
- **The risk register.** The risk overview counts vendors tracked and reviews overdue, beside risks in money.

Where an x ends up: x, found.

## Specs: delivery and data

- **Delivery:** SaaS, from one login.
- **Isolation:** Each customer runs in an isolated workspace with its own database.
- **Certifications:** None held. Frameworks are mapped to and assessed against.

## Frameworks

- Mapped to NIST AI RMF: Catalogue holds a third-party and supply chain control.
- Cross-mapped to NIS2: Supply chain control, cross-mapped in the catalogue.

## What it does not do

- The vendor register is a manual list; ColossalX sends no vendor questionnaires.
- It lists the AI vendors your gateway and app catalogue reveal, not every supplier you have.
- Starter scores in the app catalogue are editorial judgements to re-assess, not measurements.
- Risk Sync sends out only; nothing written in a GRC tool comes back.

*Illustration:* Vendor list · stated plainly: Built from Gateway and app catalogue; Register A manual list; Questionnaires Not sent from here; Risk Sync Outbound only. Record, not workflow.

## Questions

### What is third-party AI risk?

Third-party AI risk is the exposure that comes from AI you rely on but do not run yourself: a model provider, an AI feature inside a tool, a GenAI app your people use. The risk is often not the vendor but that nobody assessed it. ColossalX builds the list from your gateway and app catalogue and flags vendors in use but not assessed.

### How do you find which AI vendors your company uses?

Start from what is really in use rather than from a list someone typed. ColossalX reads the AI providers configured on your gateway and the apps in your AI app catalogue, and a discovery scan can add vendors that nobody configured. It then lays that against your register and labels each vendor.

### What does "in use, not assessed" mean for an AI vendor?

It means the vendor appears in your real AI use, through a gateway provider or a catalogue app, but nothing in your records shows it was assessed. The other labels are Assessed; Record only, where it is assessed but nothing shows it in use; and Self-hosted, where no third party is involved.

### Does ColossalX send vendor security questionnaires?

No. The vendor register is a record you keep: a vendor with its category, risk tier, contract expiry and last assessment. There is no questionnaire workflow, and ColossalX does not send questionnaires or collect answers. What it adds is the inventory of vendors in use, so you know which ones to assess first.

### Can the risk register be sent to our GRC tool?

Yes, outbound only. Risk Sync sends the register to a signed webhook or into your ticketing connection, for new or critical risks or the events you choose. Deliveries are signed, retried and replayable, and nothing is pulled back, so a tool outside cannot change the register.

## Related

- [Risk quantification](https://colossalx.tech/platform/risk-quantification)
- [Shadow AI](https://colossalx.tech/platform/shadow-ai)
- [Compliance and AI governance](https://colossalx.tech/platform/compliance)

---

ColossalX is an AI security and governance platform from Quantexra Labs LLP, delivered as SaaS. Book a walkthrough: https://colossalx.tech/demo · client.success@quantexra.tech