AI Vendor Evidence Gap Notes #2
A trust center is useful.
It is not the review.
That distinction matters in AI vendor risk assessment.
Many vendors point buyers to a trust center when asked about security, privacy, subprocessors, assurance reports, data handling, or AI use.
That is reasonable.
A trust center can reduce document-request friction. It can help the buyer locate relevant materials and understand what evidence surfaces the vendor makes available.
But it should not be treated as the conclusion.
The review question is not:
Does the vendor have documents?
The review question is:
What do those documents establish for this product, plan, use case, data type, region, contract scope, and evidence date?
That is where the evidence gap begins.
Claim
The vendor says:
“Our trust center contains our security and privacy documentation.”
Or:
“You can find our AI, privacy, and security materials in the trust center.”
Or:
“Our compliance evidence is available through the security portal.”
These statements may establish that the vendor operates a customer-assurance process.
They do not establish that the buyer’s specific AI workflow has been reviewed.
Why it sounds sufficient
A trust center looks organized.
It may include SOC reports, ISO certificates, security summaries, privacy terms, subprocessors, data-processing terms, AI FAQs, penetration-test summaries, product controls, and policy statements.
It feels official.
It feels current.
It feels review-ready.
That is the risk.
A well-designed trust center can make source material look as though the assessment work has already been completed.
It has not.
A portal may tell the buyer which documents exist.
It does not automatically show:
which claim each document supports;
whether the source applies to the relevant product and plan;
whether the evidence is current;
whether public claims match contractual terms;
whether the buyer’s data types follow the described path;
which questions remain unanswered.
The trust center organizes evidence surfaces.
The reviewer still has to convert them into a review record.
What it actually proves
A trust center may establish that the vendor publishes or provides controlled access to security, privacy, compliance, legal, and operational materials.
It may show that the vendor:
maintains a customer-assurance surface;
provides access to reports or certifications;
publishes security and privacy documentation;
identifies subprocessors or data-processing terms;
maintains a process for buyer evidence requests;
updates selected documents over time.
These are useful evidence points.
They establish that source material is available.
They do not establish that the material is sufficient for the buyer’s intended use.
A public evidence example
The CodeYourCompliance public evidence profile for Lovable records several public evidence surfaces observed as of 27 June 2026, including Lovable’s Trust Center, security page, DPA, subprocessor disclosure, AI data-use documentation, privacy material, and legal pages.
The profile is an evidence index.
It is not a security assessment, implementation verification, certification, or vendor recommendation.
Lovable’s security page links to its Trust Center and presents claims about data residency, model training, workspace isolation, monitoring, access controls, audit logs, and enterprise security features.
Those claims are relevant to a buyer review.
But they do not all carry the same scope or source strength.
Lovable’s separate enterprise legal documentation page lists General Terms, Product Terms, a DPA, a subprocessor list, a DORA addendum, definitions, and a legal change log. Each document has its own purpose and update date.
The DPA, for example, applies within a defined agreement and plan boundary. It describes processing roles, security obligations, subprocessors, retention, support access, service data, and AI or machine-learning use.
The legal change log adds another evidence dimension: time. It records when selected legal documents were added or changed, including updates related to subprocessors, customer data, AI output, and DPA language.
This is more useful than treating the Trust Center as one undifferentiated answer.
The Trust Center helps locate evidence.
The security page states product claims.
The DPA defines contractual processing terms.
The subprocessor list identifies third parties.
The change log records document changes.
These are connected evidence surfaces.
They are not interchangeable.
The buyer still needs to determine which source supports which claim for the actual product, plan, configuration, region, data type, and contract.
What it does not prove
A trust center does not automatically establish:
Product scope. A company-level portal may contain evidence that applies to one product, deployment model, or service but not another.
Plan scope. Enterprise controls, contractual commitments, audit reports, or regional options may not apply to free, individual, team, business, or API plans in the same way.
Feature scope. New AI features, integrations, agents, beta functions, connectors, or model routes may not be reflected in older assurance material.
Data-type coverage. A privacy or security statement may not distinguish prompts, outputs, code, files, logs, metadata, embeddings, support records, telemetry, or derived data.
Operational implementation. A policy, FAQ, or security statement does not independently prove that the described control operates as stated.
Contractual commitment. A public webpage may describe product behaviour without creating the same commitment as a DPA, order form, security addendum, or negotiated term.
Evidence freshness. A portal may remain live while individual reports, certificates, subprocessors, features, or legal terms change.
Customer-specific applicability. Public material does not show the buyer’s tenant settings, enabled integrations, selected region, negotiated terms, or actual workflow.
A trust center can therefore be extensive while the review remains incomplete.
Weak-answer pattern
This is the trust-center handoff pattern.
The buyer asks for evidence.
The vendor sends a trust center link.
The reviewer saves the link and records:
Trust center reviewed.
Then the review moves on.
But the file does not preserve:
which claim was tested;
which document supported it;
which product or plan it covered;
when the evidence was accessed;
whether the source was public, contractual, audited, or customer-specific;
which parts of the data path remained unclear;
which questions still required a vendor response.
That is document collection.
It is not evidence conversion.
Evidence request
Do not ask only:
Can you provide your trust center?
Ask the vendor to map its evidence to the intended use.
A stronger request is:
Please identify the specific Trust Center, product, legal, contractual, and assurance materials that support the claims relevant to this product, plan, use case, data type, region, and configuration. For each claim, identify the applicable source, evidence date, scope, exclusions, and whether the commitment is public, contractual, audited, or customer-specific.
Then ask:
Which documents apply to the exact product and plan?
Which sources cover prompts, outputs, files, code, metadata, logs, support access, and derived data?
Which claims are supported by the DPA or order form rather than only a public page?
Which assurance reports cover the relevant system and reporting period?
Which subprocessors and model providers apply to the enabled features and region?
Which materials have changed since the last review?
Which questions require private or customer-specific evidence?
The goal is not more links.
The goal is claim-to-evidence mapping.
Review note
A weak review note says:
Trust center reviewed.
A stronger review note says:
The vendor maintains a Trust Center and related public security, privacy, legal, subprocessor, and AI data-use materials. These sources support general review preparation but have not yet been fully mapped to the specific product, plan, use case, data types, configuration, region, contract terms, and evidence date. Further clarification is required for data flow, retention, logging, support access, model-provider routing, subprocessors, deletion, and customer-specific commitments.
That note preserves the source.
It also preserves the gap.
Usage boundary
Where the available trust-center materials do not establish the intended workflow:
Limit use to low-sensitivity test or internal data. Do not introduce customer-confidential data, regulated data, source code, employee records, privileged business material, or externally relied-upon outputs until the relevant product scope, data path, retention, subprocessors, support access, logging, regional handling, and contractual commitments are evidenced.
That is not a vendor rejection.
That is review preparation.
The review unit is:
vendor + product + plan + use case + data type + region + contract terms + evidence date.
A vendor name is too broad.
A trust center link is too broad.
The review begins when each claim is mapped to a source and each remaining gap is preserved.
A trust center is useful evidence infrastructure.
It is not an AI vendor risk assessment.
Boundary
This material is for evidence structuring and review preparation. It does not provide legal, regulatory, audit, procurement, certification, or implementation advice.
The goal is not to approve or reject a vendor.
The goal is to make the evidence gap visible before real data use.
Reply if you want the sanitized sample evidence gap memo.
#ThirdPartyRisk #VendorRisk #Privacy