Five pillars. 57 criteria.
One published rubric.

No dedicated AI page or section exists. AI is not addressed in any standalone trust, policy, or governance document. A page titled 'AI' that contains only one or two sentences of marketing copy is also scored here.

AI is referenced on a general trust, security, or privacy page but does not have a dedicated section or page. Or a standalone AI page exists but the content is exclusively brand/aspirational language with no operational disclosure (system inventory, governance, consumer rights).

A standalone AI policy page or trust center section exists, is reachable within one click from the main navigation, footer, or trust center, and contains substantive operational disclosure. The page addresses at least three of: AI system inventory, governance roles, risk management practices, data handling, or consumer rights mechanisms.

No public enumeration of AI systems or capabilities. Only generic phrases like 'we use AI' or 'AI-powered' without naming any specific system or feature.

Categories of AI use are listed (e.g., 'we use AI for fraud detection and personalization') but specific systems, models, or product-feature mappings are absent. Or some AI systems are inventoried but the inventory is materially incomplete relative to the company's known AI footprint as reflected in marketing, product docs, or investor materials.

A system-level inventory names specific AI systems or capabilities, identifies which products or features use each system, indicates whether each is used in consequential decisions about individuals (per SB 26-189 §6-1-1701(3)), and is specific enough for a reader to distinguish what is automated from what is not.

No disclosure of third-party AI providers. The company neither names AI vendors nor acknowledges reliance on external AI systems, even where third-party AI is materially present (e.g., a known OpenAI integration not disclosed anywhere).

Third-party AI is referenced in general terms (e.g., 'we partner with leading AI providers') without naming providers, or providers are named in one location (e.g., a sub-processor list) without mapping them to specific features.

Specific AI providers are named (OpenAI, Google, Anthropic, AWS Bedrock, Azure OpenAI Service, etc.) and the products or features that rely on each provider are identified. A reader can trace any AI-driven feature back to its underlying provider.

Terms of service contain no reference to AI, machine learning, automated systems, or algorithmic features.

Terms contain generic AI language (e.g., 'we may use automated tools' or a single disclaimer that AI outputs may be inaccurate) without specifying which features are affected, what user rights apply, or what limitations are acknowledged.

Terms address AI features specifically, identifying what is automated, user rights regarding AI-driven outputs (correction, opt-out where applicable, appeal), explicit limitations of AI accuracy, and data usage in AI contexts (whether user inputs are used for training).

AI features are present in the product but carry no labeling, badging, or in-interface indication that they are AI-powered.

Some AI features are labeled (badge, sparkle icon, 'generated by AI' tag) but labeling is inconsistent across the product, or labeling is present in marketing but not in the production interface where decisions or outputs are surfaced.

AI features are consistently labeled in the product interface where they are used. A user encountering an AI-driven output can identify it as AI-driven without leaving the screen. Labels are persistent (not transient), and labeling extends to AI-generated content (text, images, summaries, recommendations).

No documentation exists for AI-powered features beyond marketing descriptions or one-line product page mentions.

Some AI features have help center articles or brief descriptions, but documentation is incomplete (covers only the most prominent features) or lacks operational detail about what data the feature uses, what it produces, and how to control or disable it.

Each material AI-powered feature has published documentation covering its purpose, what data it uses, what it produces, known limitations or failure modes, and how to disable, override, or report concerns about it. Documentation is reachable from the product, the help center, or both.

No disclosure of AI use in internal operations, even where the company is known to use AI internally (e.g., AI-assisted hiring tools, performance analytics).

Internal AI use is referenced in general terms (e.g., 'we use AI to improve our operations') without identifying specific applications. Or only some internal applications are disclosed (e.g., customer support triage mentioned but AI-assisted hiring is not).

Specific internal AI applications, the operations they affect, whether they materially influence consequential decisions about individuals (particularly hiring and performance decisions), and what human oversight applies are all identified.

No AI-related disclosures in any regulatory filings or investor materials, including where AI is material to the business model.

AI is mentioned in risk factors or management discussion in generic terms (e.g., 'we face risks related to AI' or 'AI regulation is evolving') without describing specific material AI dependencies, governance arrangements, or operational risk controls.

Filings contain specific AI governance statements, identify material AI dependencies (named providers, named systems), and describe AI-related risk factors with operational detail including mitigation. The disclosure substantively informs an investor's understanding of AI exposure.

No mapping between AI providers, models, and product features. AI providers may be listed (e.g., on a sub-processor list) but with no indication of which features they support.

AI providers and some product feature relationships are disclosed but the mapping is incomplete, scattered across multiple documents, or limited to a subset of features.

A clear, consolidated mapping of which AI providers and which models power which product features is published. A reader can trace any AI-driven feature to its underlying provider and model family.

AI disclosures are undated, or carry dates more than 18 months old, or are inconsistent (different dates in different locations for the same policy).

Some disclosures are dated and current; others are undated, stale, or inconsistent. No version control is evident across the disclosure suite.

All material AI disclosures carry dates or version numbers within the last 12 months. Changes are tracked through visible changelogs, version history, or 'last updated' timestamps. Where policies have been revised, the prior version is either preserved or summarized.

The company develops or licenses AI used in consequential decisions but no technical documentation is available to deployers. Or documentation exists but addresses none of the four required elements under SB 26-189 §6-1-1702(1). Or documentation is exclusively marketing material.

Technical documentation is available (developer guides, model cards, integration documentation) but coverage of the four required elements is incomplete. Common partial patterns: intended uses are documented but training data categories are not; limitations are listed generically without identifying specific circumstances where the system should not be used; documentation is provided only under bespoke NDA, limiting deployer due diligence accessibility.

The developer publishes (or makes available under standard commercial terms not requiring custom negotiation) technical documentation covering all four required elements with operational specificity: (a) intended uses and known harmful/inappropriate uses; (b) training data categories; (c) known limitations including specific 'do not use' circumstances; (d) instructions for appropriate use, monitoring, and meaningful human review sufficient to support deployer compliance with SB 26-189 §6-1-1704.

No published process for notifying deployers of changes. Updates occur without documented notification. The company does not address material updates in developer documentation, contracts, or release practices.

A general changelog or release notes practice exists but does not distinguish material updates (per SB 26-189 §6-1-1701(14)) from routine maintenance. Or notification is documented for some categories (e.g., security patches) but not for changes affecting outputs, intended use, limitations, or risk mitigation. Or notification is provided only after the fact rather than within a reasonable time.

A documented process specifies: (a) what constitutes a material update versus routine maintenance, (b) the channel through which deployers receive notification, (c) the timing standard for notification, and (d) the content of the notification including the nature of the change and implications for deployer use or human review. Per §6-1-1702(2)(b), public release notes are acceptable if direct notice of the public release is also provided to each deployer.

Privacy policy contains no reference to AI, machine learning, automated processing, or algorithmic systems.

Privacy policy mentions AI or automated processing in general terms (e.g., 'we may use automated tools to process your data') but does not identify specific AI systems, data types processed by AI, or purposes of AI processing.

Privacy policy contains a dedicated AI section identifying which data is processed by AI systems, for what purposes, which AI systems are involved, and what rights users have regarding AI processing (including the right to correct personal data used in ADMT decisions per SB 26-189 §6-1-1705).

DPA contains no reference to AI processing, model training, or AI-specific data handling.

DPA references AI processing in general terms but lacks specifics on whether customer data is used for model training, how data flows through AI inference, AI-specific retention periods, or contractual commitments regarding AI data handling.

DPA contains specific provisions addressing whether customer data is used for model training (with explicit opt-out or default-off language), how data flows through AI inference, AI-specific retention and deletion timelines, and contractual commitments regarding the use, retention, and sharing of customer data in AI contexts.

No sub-processor list exists, or the sub-processor list contains no AI-related entries despite known AI integrations.

A sub-processor list exists and includes some AI providers, but coverage is incomplete (known AI features have no corresponding sub-processor entry), or providers are listed without specifying their AI processing role or data categories handled.

A published sub-processor list explicitly identifies AI-related sub-processors, the AI processing activities each performs, the data categories handled, the geographic location of processing, and the contractual basis for the relationship.

No AI-specific data retention disclosures. General retention policy, if any, does not address AI data flows.

General retention periods are disclosed but no distinction is made for data processed by AI systems. Or AI retention is mentioned without specific time periods or deletion procedures.

AI-specific retention periods are disclosed for input data, inference outputs, logs, and (where applicable) training data. Deletion procedures and deletion-on-request timelines are documented. Disclosure separates retention by data category and processing purpose.

No training opt-out mechanism exists or is disclosed. The company does not address whether user data is used for training.

The company states a training data policy (e.g., 'customer data is not used for training' or 'data may be used for training') but provides no opt-out mechanism, or an opt-out exists but is undocumented or difficult to find.

A clear, accessible training data opt-out mechanism is published. The company discloses its default training data policy and provides a documented process for opting out (or confirms by default that no customer data is used for training).

No information about model origin, type, version, or provenance is publicly available.

The company references using AI models but provides limited provenance detail (e.g., 'powered by advanced AI' without naming models, versions, or distinguishing proprietary from third-party).

Model provenance is disclosed: whether models are proprietary, open-source, or third-party; specific models or model families are named where applicable; and version or update information is sufficient to support SB 26-189 §6-1-1704(3)(b) deployer disclosures.

No disclosure of data categories or sources used in AI systems.

General categories of data used in AI are disclosed (e.g., 'usage data, customer data') but the sourcing, scope, or flow is not explained.

Specific data categories used in each AI system, their origin (user-provided, observed, inferred, third-party), and how data flows into AI processing are disclosed. Detail is sufficient to support SB 26-189 §6-1-1704(3)(b) downstream consumer disclosure obligations.

No disclosure of whether AI-processed data is shared with third parties.

General data sharing disclosures exist but do not specifically address data shared through AI systems or with AI providers.

Specifically discloses what data is shared with AI providers, for what purposes, under what contractual protections, and whether AI providers may retain or reuse the data for their own purposes (including model training).

No model cards, system cards, or structured AI system documentation is publicly available.

Some documentation exists for AI features but does not follow a structured format covering intended use, limitations, and known risks. Or structured docs exist for some systems but not all material AI features.

Structured model cards or system documentation is published for material AI systems, covering intended use, limitations, performance characteristics, known biases or risks, and evaluation results. Documentation aligns with widely-recognized formats (e.g., the model card framework from Mitchell et al. 2019, or system cards).

No public statements about data quality, representativeness, or bias in AI training or operational data.

General statements about data quality or fairness commitments exist but without specific practices, metrics, or assessment procedures.

Specific data quality practices, representativeness assessments, or bias evaluation results are published with enough detail (methodology, datasets evaluated, findings) to evaluate the rigor of the process.

No correction mechanism for personal data used in ADMT decisions is published. The company does not address consumer rights to correct factually inaccurate inputs to automated decisions.

A general data correction mechanism exists (e.g., under CCPA, GDPR Article 16, or CPA) but it is not specifically extended to data used in covered ADMT decisions, or the process for invoking the right in the ADMT context is undocumented. Or the mechanism is documented but does not explain how a consumer requests reconsideration of an ADMT decision after correction.

A documented mechanism allows consumers to request: (a) access to the personal data used in a specific ADMT decision; (b) correction of factually incorrect or materially inaccurate personal data used in that decision; and (c) reconsideration of the decision following correction. The mechanism is reachable from the post-adverse outcome notice (per P4-11) and from the privacy policy. The exception for opinions, predictions, scores, and protected evaluations under §6-1-1705(1)(c) is appropriately scoped.

No published risk management framework, policy, or statement addresses AI-specific risks.

A general risk management or security policy exists but does not specifically address AI systems. Or an AI risk statement exists but lacks operational detail (no defined risk categories, no assessment process, no response procedures).

A published AI risk management framework or policy identifies AI-specific risk categories, describes the assessment and monitoring process, defines response procedures, and is specific enough to demonstrate operational commitment beyond aspirational language.

No reference to any recognized AI governance framework or standard.

The company references an AI governance framework but does not describe how it is applied (e.g., 'We are committed to the NIST AI RMF' without operational detail).

A specific framework is referenced, practices are mapped to specific functions or clauses, and detail is sufficient to demonstrate substantive alignment rather than aspirational reference. Where certification has been pursued (e.g., ISO/IEC 42001), it is identified by certificate registry entry or attestation.

No published incident response policy addresses AI, or no incident response policy exists at all.

A general incident response policy exists but does not address AI-specific incidents. Or AI incident response is referenced but without defined roles, timelines, or escalation paths.

A published incident response policy addresses AI-specific incidents, defines response roles, includes escalation timelines, and distinguishes AI incidents (model failure, harmful output, drift, training data issues) from general security incidents. Where serious-incident reporting obligations apply (e.g., EU AI Act Article 73), the policy references the reporting process.

No published procedures for human oversight of AI-driven decisions.

General statements about human oversight exist (e.g., 'our teams review AI outputs') but no specific procedures, triggers, or decision boundaries are documented.

Published procedures define when human review is triggered, who performs it, what decision authority humans retain, and how human override of AI outputs is documented. Procedures are specific to identified AI use cases.

No escalation path for AI-related concerns is published or accessible.

General contact channels exist (e.g., support email) but no AI-specific escalation path or process is documented.

A documented escalation path exists for AI-related concerns, with defined intake channels, response expectations, and routing to appropriate internal teams. Users, customers, or affected parties can identify how to raise AI-specific issues, including how to invoke consumer rights under SB 26-189 §6-1-1705.

No disclosure of AI audit, assessment, or review cadence.

The company references conducting AI assessments or reviews but does not disclose cadence, scope, or whether reviews are internal, external, or both.

A defined audit or assessment cadence for AI systems is disclosed (annual, quarterly, continuous), the scope is identified (which systems, which risks), reviews are indicated as internal, external, or both, and the standards used (NIST AI RMF, ISO/IEC 42001 certification, third-party audit reports) are referenced.

No public identification of roles or teams responsible for AI governance or risk management.

General governance language exists (e.g., 'our teams ensure responsible AI') without identifying specific roles, teams, or reporting lines.

Specific roles, teams, or governance bodies (e.g., Responsible AI team, AI Ethics Board, Chief AI Officer, AI Risk Committee) are identified with enough detail to understand reporting structure and accountability. Where applicable, board-level oversight responsibility is disclosed.

No published responsible AI policy, ethics statement, or AI principles.

An AI principles or ethics page exists but contains only aspirational language without operational commitments (e.g., 'we believe in responsible AI' without describing practices).

A published responsible AI policy or principles document includes specific operational commitments (fairness testing methodology, bias monitoring procedures, red-teaming practices, model evaluation criteria) that can be evaluated against actual practice.

No disclosure of AI performance monitoring procedures.

The company references monitoring AI systems but does not describe what is monitored, how frequently, or what thresholds trigger intervention.

Published procedures describe what AI performance metrics are tracked, how frequently monitoring occurs, what thresholds or triggers initiate review or intervention, and how feedback is incorporated into system updates. Where post-market monitoring obligations apply (EU AI Act Article 72), the procedure is disclosed.

No public reporting on AI risks, incidents, or governance outcomes.

Some public reporting exists (e.g., a transparency report) but does not specifically cover AI risks or incidents, or covers them in minimal detail.

The company publishes reporting specifically addressing AI governance outcomes, incident summaries, risk trends, or impact assessments. Reporting is periodic (annual or biannual) or event-driven with a defined publication practice.

No published procedures for human review of ADMT decisions. Or general human-review language exists (covered under P3-04) but none of the four statutory elements of meaningful human review are addressed. Or the only 'human review' is rubber-stamping of system outputs.

Procedures address some statutory elements but not all four. Common partial patterns: reviewer authority to modify or override is stated, but training requirements are not specified; reviewers receive system output but not the principal factors used to generate it; review is documented but the 'does not default to system output' standard is not addressed; the consumer right to request reconsideration exists but the procedure or timeline is undocumented.

Published procedures address all four statutory elements: (a) reviewers consider relevant, available primary evidence beyond the system output; (b) reviewers are trained to conduct the review with documented training scope; (c) reviewers are explicitly authorized and instructed not to default to system output; (d) reviewers receive sufficient information about intended use, material limitations, categories of inputs, and principal factors (without disclosure of proprietary source code, model weights, or trade secrets). The consumer right to request meaningful human review and reconsideration is documented with timeline and process.

No published record retention practice addressing AI systems. The company does not address how long it retains AI system documentation, version histories, or decision records. Or stated retention periods are shorter than three years.

A general record retention policy exists but does not specifically address the categories required by SB 26-189 (system version identifiers, changelogs, material update documentation, mitigation documentation). Or retention is asserted at three years but the categories of records retained are not specified. Or the deployer-specific obligation to retain consequential decision records is unaddressed.

A documented retention practice specifies: (a) the three-year minimum aligned with SB 26-189, (b) the categories of records retained (system version identifiers, changelogs, material update notices, mitigation documentation, and for deployers, records tied to consequential decisions), (c) the storage and access controls applied, and (d) the deletion process at the end of the retention period. Where longer retention is required by other state or federal law, the longer period is referenced.

No disclosure of which decisions affecting individuals involve AI or automated processing.

The company acknowledges using automated decision-making in general terms but does not identify which specific decisions are automated, or what domains (e.g., hiring, pricing, eligibility) are affected.

Specific decisions that are AI-informed or AI-driven are identified, along with the covered domains in which they operate (per SB 26-189 §6-1-1706(1): education, employment, housing, financial/lending, insurance, healthcare, essential government services), and the degree of human involvement in each. The disclosure distinguishes consequential decisions from low-stakes or routine processing.

No explanation of AI decision logic is available for any automated decision affecting individuals.

General explanations exist (e.g., 'our AI considers multiple factors') but do not identify specific inputs, principal factors, or logic for any specific decision type.

Decision-specific explanations identify the factors considered, how inputs influence outputs, and the principal factors used to generate the output, without requiring disclosure of proprietary source code, model weights, or trade secrets (per SB 26-189 §6-1-1701(15)(d)). Explanations are specific enough for an affected individual to understand why a particular outcome occurred.

No published procedure for adverse decision notification.

General complaint or feedback channels exist but no specific procedure for adverse AI decision notification is documented.

A published procedure describes how affected individuals are notified of adverse AI-driven decisions, what information is provided in the notice, and the channels through which notice is delivered. Sector-specific notice obligations (ECOA Regulation B, FCRA) are referenced where applicable.

No appeal mechanism or human review option for AI-driven decisions is published.

General appeals or complaint processes exist but are not specifically tied to AI-driven decisions, or a human review option is referenced but the process, timeline, and reviewer authority are not documented.

A documented mechanism allows individuals to appeal AI-driven decisions to a human reviewer with stated authority to approve, modify, or override the decision (consistent with the meaningful human review definition). Process, timeline, contact method, and outcome notification process are published.

No opt-out mechanism for automated decision-making or profiling is disclosed.

An opt-out mechanism exists for some automated decisions or profiling but is not comprehensive, or the mechanism is documented but difficult to exercise.

A clearly documented, accessible mechanism for opting out of automated decision-making and profiling where opt-out is legally available. The scope of the opt-out (which decisions, which profiling activities) is clearly defined.

No disclosure of profiling activities.

The privacy policy references profiling or personalization in general terms but does not identify what data is used to build profiles, what profiles are used for, or how profiles influence decisions.

The company discloses what profiling activities it conducts, what data inputs are used, what decisions or experiences are informed by profiles, and what rights individuals have regarding profiling (access, correction, opt-out).

No system cards, algorithmic disclosures, or impact assessments are published for any AI system.

Some documentation exists for algorithmic systems but does not follow a structured disclosure format and lacks coverage of impact, affected populations, or risk assessment.

Structured system cards or algorithmic disclosures are published for material AI systems used in consequential decisions, covering intended use, affected populations, decision processes, performance metrics, and identified risks.

No consumer rights mechanisms specific to AI are accessible or discoverable.

Consumer rights mechanisms exist but are buried in policy text, require multiple steps to discover, or require specialized knowledge to exercise.

Consumer rights mechanisms are prominently linked, easy to discover (within two clicks of the homepage or product interface), and can be exercised without specialized knowledge or undue burden. Channels include web form, email, and where applicable, telephone. (Disability and limited-English-proficiency accessibility is separately scored under P4-12.)

No inventory or classification of consequential AI decisions is published.

Some AI decisions are described as 'consequential' or 'high-impact' but no systematic inventory exists, or the inventory does not align with the SB 26-189 statutory definition.

An inventory of consequential AI decisions aligned with the SB 26-189 definition is published, identifying the covered domain (education, employment, housing, financial/lending, insurance, healthcare, essential government services), the nature of the decision, and the role of the covered ADMT. Exclusions under §6-1-1701(3)(b) (low-stakes routine decisions, advertising/marketing, cybersecurity, fraud prevention) are appropriately scoped.

No pre-decision point-of-interaction notice is provided. Consumers interact with covered ADMT without any indication that automated technology will influence a consequential decision affecting them.

A general privacy policy or terms of service references AI use but no clear and conspicuous notice is provided at or near the point of interaction. Or notice is provided only after the decision, not before. Or notice references AI generally but does not indicate that it will materially influence a consequential decision affecting the consumer.

A clear and conspicuous notice is provided at or reasonably proximate to the point of consumer interaction, identifying that a covered ADMT will be used in a consequential decision affecting the consumer and providing instructions for obtaining the additional information described in §6-1-1704. The notice meets the public-posting alternative if a prominent, reasonably accessible posting is in place per §6-1-1704(2).

No post-adverse outcome disclosure procedure exists, or disclosure is not tied to the 30-day window, or disclosure addresses none of the three required elements.

A post-adverse outcome disclosure procedure exists but coverage of the three required elements is incomplete. Common partial patterns: a plain language description of the decision is provided but the role of the covered ADMT is not specified; rights are mentioned but the process to exercise them is not documented; ADMT name and version are not consistently provided; the 30-day window is not stated. For creditors, the ECOA/FCRA safe harbor (§6-1-1704(6)) is invoked but the notice does not also include the brief ADMT statement and instructions for additional information.

Within 30 days after the adverse outcome, the consumer receives a disclosure that includes: (a) plain language description of the decision and the covered ADMT's role; (b) ADMT name, version (if applicable), developer, types/categories/sources of personal data used, and a simple-to-follow process to request additional information; (c) explanation of consumer rights under §6-1-1705 (correction, meaningful human review, reconsideration) and how to exercise them. Where the creditor safe harbor under §6-1-1704(6) applies, the ECOA/FCRA notice includes the brief ADMT statement and additional-information instructions. Format is appropriately accessible (see P4-12).

Required SB 26-189 notices and disclosures are available only in English and only in non-accessible formats (e.g., PDFs that fail accessibility checks, web pages that fail WCAG criteria).

Some accessibility accommodations are in place (e.g., alt text on web disclosures, Spanish-language version of one notice) but coverage is incomplete across the disclosure suite, or non-English language coverage does not extend to the languages most commonly spoken by affected consumers, or accessibility conformance is not stated.

The notices and disclosures required by SB 26-189 (point-of-interaction, post-adverse outcome, consumer rights mechanisms) are available in formats reasonably accessible to consumers with disabilities (WCAG 2.1 AA conformance or stated equivalent) and in languages reasonably accessible to consumers with limited English proficiency, consistent with applicable state and federal law. Accessibility is stated and verifiable.

No recognized security certifications are disclosed or verifiable through public registries.

The company holds general security certifications (e.g., SOC 2 Type II, ISO/IEC 27001) but does not confirm that the scope of certification includes AI system infrastructure.

Recognized certifications are held and the company confirms (or documentation shows) that the scope of certification includes the infrastructure supporting AI features. Certification is current and verifiable through certificate registries, attestation letters, or audit summaries.

No AI-specific certifications held or in progress.

The company references AI-specific standards (e.g., 'aligned with NIST AI RMF') but does not hold formal certification. Or certification is in progress but not yet completed.

The company holds a current AI-specific certification (ISO/IEC 42001 or equivalent) or can demonstrate formal conformity assessment against a recognized AI governance standard. Certification is verifiable through an accredited certification body or registry.

No vulnerability disclosure program, security reporting channel, or security.txt file is published.

A general security contact exists (e.g., security@company.com) but no structured VDP with defined scope, safe harbor, or response commitments is published.

A structured vulnerability disclosure program is published with defined scope, safe harbor provisions, response timeline commitments, and a clear submission channel. The VDP is reachable through /.well-known/security.txt or trust center.

No bug bounty program exists, or a bug bounty program exists but makes no reference to AI systems.

A bug bounty program exists and AI systems are not explicitly excluded, but AI-specific attack surfaces (prompt injection, model manipulation, training data extraction, jailbreaks) are not specifically addressed in scope.

A bug bounty program explicitly includes AI-specific attack surfaces in scope, with defined categories for AI vulnerabilities (prompt injection, model extraction, training data leakage, adversarial inputs, jailbreaks) and commensurate reward tiers.

No disclosure of penetration testing practices.

The company states that penetration testing is conducted but does not disclose cadence, scope, or whether AI systems are included.

Penetration testing cadence is disclosed (annual, biannual, continuous), AI systems are confirmed in scope, and whether testing is conducted by independent third parties is indicated. Summary results or scope statements are referenced.

No disclosure of model or training data security measures.

General data security measures are disclosed but no AI-specific protections for model weights, parameters, or training data are documented.

Specific protections for AI model weights, parameters, and training data are documented, including access controls, encryption at rest and in transit, and measures against model extraction, model inversion, or training data leakage attacks.

No disclosure of AI-specific threat defenses or adversarial robustness practices.

General references to AI safety or robustness exist but no specific practices (red-teaming, adversarial testing, input validation, prompt hardening, output filtering) are described.

Specific AI threat defense practices are disclosed: adversarial testing methodology, red-teaming exercises (internal or external), prompt injection defenses, input validation, output filtering, content moderation, or other documented mitigations. For generative AI systems, alignment to NIST AI 600-1 GenAI Profile is referenced.

No documentation of AI sub-processor security posture.

AI sub-processors are disclosed but their security posture (certifications, data handling, controls) is not documented or referenced.

The security posture of AI sub-processors is documented or referenced, including their certifications (SOC 2, ISO/IEC 27001, ISO/IEC 42001), contractual security commitments, and relevant data handling practices.

No disclosure of AI supply chain security practices.

General software supply chain practices are disclosed (e.g., dependency scanning) but AI-specific supply chain concerns (model provenance verification, model integrity checks, signed model artifacts) are not addressed.

AI supply chain security practices are documented: model provenance verification, dependency integrity checks for AI libraries, secure model update procedures, and AI-specific SBOM (or equivalent) documentation. Alignment with NIST SP 800-218A practices for generative AI is referenced where applicable.

No disclosure regarding AI-related security incidents, whether they have occurred or not.

General security incident history is disclosed (e.g., in a transparency report) but AI-specific incidents are not separately addressed.

The company either discloses AI-specific security incidents with remediation detail, or explicitly states that no AI-specific security incidents have occurred within a defined period. Incident disclosure is part of a regular reporting practice (annual or biannual).