Cytra Framework crosswalk

NIST AI RMF × ISO/IEC 42001 × EU AI Act × TRAIGA — one anchor taxonomy, four frameworks.

The Cytra Crosswalk maps NIST AI RMF sub-categories to the corresponding ISO/IEC 42001:2023 clauses and Annex A controls and EU AI Act articles — control-by-control, with mapping strength and rationale. Map once; demonstrate alignment across all three frameworks.

NIST AI RMF 1.0ISO/IEC 42001:2023EU AI Act (2024/1689)TRAIGA (Texas HB 149)

What the crosswalk is — and isn't

A published-standard mapping, not a Cytra-invented framework.

Every control identifier in this table — NIST AI RMF sub-categories, ISO/IEC 42001:2023 clause and Annex A control identifiers, EU AI Act article numbers — is drawn from the published standards (EU AI Act citations follow the final Regulation (EU) 2024/1689 numbering). Cytra did not author those standards and does not claim to. What we publish here is our interpretation of how the published requirements correspond, so that an organisation subject to more than one framework can address overlapping obligations once rather than separately.

Posture: Cytra is aligned, not certified. This crosswalk maps control objectives; it is not a conformity assessment and does not confer or imply certification under any standard. Cytra Gateway, the managed gateway that generates continuous evidence for these controls, is in private beta.

License: code Apache 2.0 · content CC BY 4.0 (attribution: Cytra / Wentzel Investments LLC). Full v1.0 expansion to 230+ control objectives tracked in Jira CYT-124.

Control-by-control mapping

NIST AI RMF × ISO/IEC 42001 × EU AI Act — each mapped sub-category with strength and rationale.

Showing 51 of 51 mappings

Framework crosswalk mapping NIST AI RMF sub-categories to ISO/IEC 42001:2023 clauses and Annex A controls and EU AI Act articles.
NIST AI RMF	Sub-category title	ISO/IEC 42001:2023	EU AI Act	Mapping note
GOVERN (15)
GOVERN GOVERN 1.1	Legal and regulatory requirements involving AI are understood, managed, and documented	§4.1 A.2.3 Direct	Art. 16 Partial	ISO §4.1 requires determining external issues — including the legal and regulatory context — and Annex A A.2.3 aligns the AI policy with other organisational policies. The EU AI Act is itself the legal obligation: Art. 16 makes providers responsible for high-risk system compliance, but the Act has no meta-requirement to track legal obligations.
GOVERN GOVERN 1.2	Characteristics of trustworthy AI are integrated into organisational policies, processes, and practices	§5.2 A.2.2 Direct	Art. 17 Partial	ISO §5.2 and Annex A A.2.2 require an AI policy that gives effect to responsible-AI commitments. EU AI Act Art. 17 (quality management system) makes providers institutionalise compliance in policies and procedures — partial, because it is framed around regulatory compliance rather than trustworthiness characteristics.
GOVERN GOVERN 1.3	Processes determine the needed level of risk management activities based on organisational risk tolerance	§6.1 §6.1.2 Direct	Art. 9 Partial	ISO §6.1.2 requires an AI risk assessment process with criteria tied to organisational risk appetite; EU AI Act Art. 9 mandates a risk management system but does not prescribe tolerance thresholds.
GOVERN GOVERN 1.4	The risk management process is established through transparent policies, procedures, and controls	§5.2 §7.5 Direct	Art. 9 Direct	ISO §5.2 (AI policy) and §7.5 (documented information) require the management process to be written down and maintained; EU AI Act Art. 9(1) requires the risk management system to be established, implemented, documented, and maintained.
GOVERN GOVERN 1.5	Ongoing monitoring and periodic review of the risk management process are planned, with roles defined	§9.1 §9.3 Direct	Art. 9 Art. 72 Direct	ISO §9.1 (monitoring, measurement, analysis, evaluation) and §9.3 (management review) institutionalise periodic review; EU AI Act Art. 9(2) makes risk management a continuous iterative process and Art. 72 requires post-market monitoring.
GOVERN GOVERN 1.6	Mechanisms are in place to inventory AI systems	A.4.2 §7.5 Partial	Art. 49 Art. 71 Partial	ISO/IEC 42001 has no dedicated inventory control; Annex A A.4.2 (resource documentation) and §7.5 (documented information) are the nearest anchors. EU AI Act Art. 49 requires registration of high-risk systems in the Art. 71 EU database — a regulatory inventory, narrower than an organisation-wide one.
GOVERN GOVERN 1.7	Processes are in place for safely decommissioning and phasing out AI systems	§8.1 A.6.2.6 Partial	Art. 72 Partial	Neither standard has a dedicated decommissioning control. ISO §8.1 (operational planning and control) and Annex A A.6.2.6 (AI system operation and monitoring) cover the operational lifecycle; EU AI Act Art. 72 (post-market monitoring) would surface decommission triggers.
GOVERN GOVERN 2.1	Roles, responsibilities, and lines of communication for AI risk management are documented	§5.3 A.3.2 Direct	Art. 17 Art. 26 Partial	ISO §5.3 and Annex A A.3.2 require AI roles and responsibilities to be assigned and communicated. EU AI Act Art. 17(1)(m) requires an accountability framework setting out management and staff responsibilities, and Art. 26 fixes deployer-side duties — partial, because the Act allocates duties to actor categories rather than internal roles.
GOVERN GOVERN 2.2	Personnel and partners receive AI risk management training	§7.2 §7.3 Direct	Art. 4 Direct	ISO §7.2 (competence) and §7.3 (awareness) require demonstrably competent, aware personnel; EU AI Act Art. 4 requires providers and deployers to ensure a sufficient level of AI literacy of their staff.
GOVERN GOVERN 3.1	AI risk decision-making is informed by a diverse team (demographics, disciplines, experience, expertise)	A.4.6 Related	Gap	Neither framework mandates team diversity. Annex A A.4.6 (human resources) is the nearest ISO control — it covers the people needed across the AI life cycle. The EU AI Act has no counterpart obligation; the gap is recorded rather than forced.
GOVERN GOVERN 4.1	Organisational practices foster a critical-thinking and safety-first mindset for AI	§5.1 §7.3 Partial	Art. 4 Related	Organisational culture is not directly legislated. ISO §5.1 (leadership and commitment) and §7.3 (awareness) are the nearest management-system levers; EU AI Act Art. 4 (AI literacy) is related at best.
GOVERN GOVERN 4.2	Teams document and communicate the risks and impacts of the AI they design, develop, deploy, and use	§6.1.4 A.5.2 A.5.3 Direct	Art. 9 Art. 27 Partial	ISO §6.1.4 plus Annex A A.5.2/A.5.3 require an AI system impact assessment process with documented results. EU AI Act Art. 9 requires documented risk management and Art. 27 a fundamental rights impact assessment — partial, since the FRIA binds only certain deployers.
GOVERN GOVERN 5.1	Feedback from those external to the team on individual and societal impacts is collected and integrated	§4.2 A.8.3 Partial	Art. 72 Partial	ISO §4.2 (interested parties) and Annex A A.8.3 (external reporting channels for adverse impacts) approximate external feedback intake; EU AI Act Art. 72 post-market monitoring must collect deployment-experience data. None of the three is a full public-engagement mandate.
GOVERN GOVERN 6.1	Policies address AI risks from third-party entities, including infringement of third-party IP or other rights	A.10.2 A.10.3 Direct	Art. 25 Partial	Annex A A.10.2/A.10.3 govern responsibility allocation and supplier processes for third parties. EU AI Act Art. 25 (responsibilities along the AI value chain) covers when third parties assume provider obligations — partial, since the Act does not regulate IP-infringement risk here.
GOVERN GOVERN 6.2	Contingency processes handle failures or incidents in high-risk third-party data or AI systems	§10.2 A.10.3 Partial	Art. 15 Art. 73 Partial	ISO §10.2 (nonconformity and corrective action) plus Annex A A.10.3 (suppliers) approximate third-party contingency handling; EU AI Act Art. 15 requires technical resilience (including backup and fail-safe plans) and Art. 73 serious-incident reporting.
MAP (10)
MAP MAP 1.1	Intended purposes, context-specific laws and norms, and prospective deployment settings are understood and documented	§4.1 §4.2 A.9.4 Direct	Art. 6 Annex III Annex IV Direct	ISO §4.1/§4.2 establish organisational and interested-party context, and Annex A A.9.4 requires the intended use of the AI system to be defined. Under the EU AI Act, intended purpose drives Art. 6 + Annex III high-risk classification and must be documented in the Annex IV technical documentation.
MAP MAP 1.3	The organisation's mission and relevant goals for AI technology are understood and documented	§4.1 §6.2 Direct	Gap	ISO §4.1 (context) and §6.2 (AI objectives) require documented organisational goals for AI. The EU AI Act regulates systems and actors, not an organisation's mission — gap recorded.
MAP MAP 1.5	Organisational risk tolerances are determined and documented	§6.1.2 Direct	Art. 9 Partial	ISO §6.1.2 requires AI risk assessment criteria, including risk acceptance criteria. EU AI Act Art. 9 requires judging which risks are acceptable but does not mandate documented organisation-wide tolerances.
MAP MAP 1.6	System requirements are elicited from relevant AI actors; design decisions account for socio-technical implications	A.6.2.2 §6.1.4 Direct	Art. 9 Related	Annex A A.6.2.2 requires AI system requirements and specification, and §6.1.4 brings socio-technical impacts into planning via the impact assessment. EU AI Act Art. 9 shapes requirements only indirectly through risk management — related, not a requirements-engineering mandate.
MAP MAP 2.1	The specific tasks and methods the AI system will support are defined (e.g. classifiers, generative models, recommenders)	A.6.2.2 Direct	Art. 11 Annex IV Partial	Annex A A.6.2.2 (requirements and specification) covers task and method definition. EU AI Act Art. 11 + Annex IV require the technical documentation to describe the system, its capabilities, and its development methods — partial: documentation of choices, not a design mandate.
MAP MAP 2.2	The AI system's knowledge limits — and how outputs may be used and overseen by humans — are documented	A.8.2 Direct	Art. 13 Art. 14 Direct	Annex A A.8.2 requires system documentation and information for users. EU AI Act Art. 13 mandates instructions for use covering capabilities and limitations, and Art. 14 requires designing for effective human oversight.
MAP MAP 3.1	Potential benefits of intended AI system functionality and performance are examined and documented	§6.1 A.5.2 Partial	Gap	ISO §6.1 addresses risks and opportunities, and the Annex A A.5.2 impact assessment process can capture beneficial as well as harmful consequences — partial. The EU AI Act has no benefit-documentation requirement; gap recorded.
MAP MAP 3.5	Processes for human oversight are defined, assessed, and documented	A.9.2 Partial	Art. 14 Direct	EU AI Act Art. 14 is the canonical human-oversight obligation (oversight by design, ability to intervene or interrupt). ISO/IEC 42001 has no dedicated human-oversight control; Annex A A.9.2 (processes for responsible use) is the nearest anchor — partial.
MAP MAP 4.1	Legal risks of AI components — including third-party data or software and IP infringement — are mapped	§4.1 A.10.3 Partial	Art. 25 Partial	ISO §4.1 (legal context) and Annex A A.10.3 (suppliers) partially cover component-level legal risk; EU AI Act Art. 25 allocates value-chain responsibilities but does not address IP-infringement mapping.
MAP MAP 4.2	Internal risk controls for AI system components, including third-party AI, are identified and documented	§6.1.3 A.10.3 Direct	Art. 9 Art. 25 Partial	ISO §6.1.3 (AI risk treatment) requires selecting and documenting controls — extended to third-party components by Annex A A.10.3. EU AI Act Art. 9 requires risk mitigation measures; Art. 25 covers third-party component providers in the value chain.
MEASURE (17)
MEASURE MEASURE 1.1	Approaches and metrics for measuring mapped AI risks are selected; unmeasured risks are documented	§6.1.2 §9.1 Direct	Art. 9 Partial	ISO §6.1.2 (risk assessment process and criteria) and §9.1 (what to monitor and measure, and how) cover measurement selection; EU AI Act Art. 9 requires risk estimation and evaluation but prescribes no metrics.
MEASURE MEASURE 1.3	Internal experts who were not front-line developers, or independent assessors, are involved in regular assessments	§9.2 Partial	Art. 43 Partial	ISO §9.2 (internal audit) institutionalises independent assessment of the management system, not of each AI system. EU AI Act Art. 43 conformity assessment brings in notified-body (third-party) assessment for some high-risk classes.
MEASURE MEASURE 2.1	Test sets, metrics, and details of the tools used during TEVV are documented	A.6.2.4 Direct	Art. 9 Annex IV Direct	Annex A A.6.2.4 requires defined verification and validation measures. EU AI Act Art. 9(6)–(8) requires testing of high-risk systems, and Annex IV requires the technical documentation to describe testing and validation procedures and results.
MEASURE MEASURE 2.2	Evaluations involving human subjects meet applicable requirements and are representative	Gap	Art. 60 Art. 61 Partial	ISO/IEC 42001 has no human-subject research control — gap recorded. EU AI Act Art. 60 governs real-world testing of high-risk systems and Art. 61 requires informed consent of participants — partial, as they cover only that testing context.
MEASURE MEASURE 2.3	AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment	A.6.2.4 §9.1 Direct	Art. 9 Art. 15 Direct	Annex A A.6.2.4 (verification and validation) plus §9.1 (measurement) cover demonstration against criteria; EU AI Act Art. 9(8) requires testing against the intended purpose and Art. 15 sets accuracy and robustness expectations.
MEASURE MEASURE 2.5	The AI system is demonstrated to be valid and reliable; limits of generalizability are documented	A.6.2.4 Direct	Art. 13 Art. 15 Direct	Annex A A.6.2.4 requires validation against requirements; EU AI Act Art. 15 requires appropriate accuracy and robustness, and Art. 13 requires limitations to be disclosed in the instructions for use.
MEASURE MEASURE 2.6	The AI system is regularly evaluated for safety risks and demonstrated to fail safely	§8.2 Partial	Art. 9 Art. 15 Direct	ISO §8.2 requires AI risk assessment at planned intervals — safety among the risks, but with no dedicated safety control (partial). EU AI Act Art. 9 targets health and safety risks directly, and Art. 15 requires robustness including technical redundancy and fail-safe plans.
MEASURE MEASURE 2.7	AI system security and resilience are evaluated and documented	A.6.2.6 Related	Art. 15 Direct	EU AI Act Art. 15 (accuracy, robustness and cybersecurity) is the direct anchor. ISO/IEC 42001 has no security control of its own — Annex A A.6.2.6 (operation and monitoring) is related at best; the security substance lives in ISO/IEC 27001.
MEASURE MEASURE 2.8	Risks associated with transparency and accountability are examined and documented	A.8.2 Partial	Art. 13 Art. 50 Direct	EU AI Act Art. 13 (transparency to deployers) and Art. 50 (disclosure duties for certain AI systems — chatbot disclosure, synthetic-content marking) address transparency risk directly; Annex A A.8.2 (system documentation and information for users) is the partial ISO anchor.
MEASURE MEASURE 2.9	The AI model is explained, validated, and documented; outputs are interpreted within context	A.6.2.4 A.8.2 Partial	Art. 13 Art. 14 Direct	EU AI Act Art. 13(1) requires operation transparent enough for deployers to interpret and use output appropriately, and Art. 14 ties interpretation to oversight. ISO Annex A A.6.2.4 (validation) and A.8.2 (user information) partially cover explainability.
MEASURE MEASURE 2.10	Privacy risk of the AI system is examined and documented	§8.2 A.5.4 Partial	Art. 10 Partial	ISO §8.2 risk assessment and Annex A A.5.4 (impacts on individuals or groups) can surface privacy harms; EU AI Act Art. 10(5) constrains special-category data processing. The authoritative privacy regime is the GDPR (e.g. Art. 35 DPIA), external to both.
MEASURE MEASURE 2.11	Fairness and bias are evaluated, and results are documented	A.7.4 Partial	Art. 10 Direct	EU AI Act Art. 10(2)(f)–(g) explicitly requires examination and mitigation of possible biases in training, validation, and testing data. ISO/IEC 42001 has no dedicated fairness control; Annex A A.7.4 (quality of data) is the partial anchor.
MEASURE MEASURE 2.12	Environmental impact and sustainability of AI model training and management are assessed and documented	§4.1 Related	Art. 95 Related	Neither framework has a mandatory environmental control. EU AI Act Art. 95(2) lists assessing and minimising environmental impact among VOLUNTARY codes of conduct; ISO §4.1 can pull sustainability in as external context. Related at best on both sides.
MEASURE MEASURE 2.13	Effectiveness of the employed TEVV metrics and processes is evaluated and documented	§9.1 Partial	Art. 9 Partial	ISO §9.1 requires evaluating the effectiveness of the management system — not of TEVV metrics specifically; EU AI Act Art. 9(2) makes risk management iterative, which implies revisiting testing adequacy. Partial on both sides.
MEASURE MEASURE 3.1	Existing, unanticipated, and emergent AI risks are regularly identified and tracked	§8.2 §9.1 Direct	Art. 9 Art. 72 Direct	ISO §8.2 requires AI risk assessment at planned intervals and §9.1 continuous monitoring; EU AI Act Art. 9(2) requires identifying known and reasonably foreseeable risks and Art. 72 post-market monitoring catches emergent ones.
MEASURE MEASURE 3.2	Risk tracking approaches are considered for risks that are difficult to measure	§6.1.2 Partial	Art. 9 Related	ISO §6.1.2 risk assessment must handle all identified risks, including hard-to-quantify ones, but neither framework prescribes techniques for unmeasurable risks. EU AI Act Art. 9 is related only.
MEASURE MEASURE 4.1	Risk measurement is connected to deployment context and informed by domain experts and end users	§4.2 §9.1 Partial	Art. 9 Partial	ISO §4.2 (interested parties) and §9.1 (measurement) approximate context-aware measurement; EU AI Act Art. 9 requires risk evaluation in view of the intended purpose and reasonably foreseeable misuse. Neither mandates expert or user consultation for metric design.
MANAGE (9)
MANAGE MANAGE 1.1	Whether the AI system achieves its intended purposes — and whether development or deployment should proceed — is determined	A.6.2.4 §8.4 Partial	Art. 43 Partial	Annex A A.6.2.4 (verification and validation) and §8.4 (AI system impact assessment) feed the go/no-go decision; EU AI Act Art. 43 gates market placement behind conformity assessment. Neither phrases it as an explicit proceed/stop determination.
MANAGE MANAGE 1.2	Treatment of documented AI risks is prioritised by impact, likelihood, and available resources	§6.1.3 §8.3 Direct	Art. 9 Direct	ISO §6.1.3 (AI risk treatment — planning) and §8.3 (AI risk treatment — operation) are the treatment clauses; EU AI Act Art. 9(3)–(5) requires appropriate, targeted, and prioritised risk management measures.
MANAGE MANAGE 1.3	Responses to high-priority AI risks — mitigate, transfer, avoid, or accept — are developed, planned, and documented	§6.1.3 §8.3 Direct	Art. 9 Direct	Risk response planning is exactly ISO risk treatment: §6.1.3 plans the treatment options and §8.3 implements the treatment plan; EU AI Act Art. 9 requires adoption of appropriate and targeted risk management measures.
MANAGE MANAGE 2.2	Mechanisms are in place and applied to sustain the value of deployed AI systems	A.6.2.6 §10.1 Partial	Art. 72 Related	Value sustainment is operational: Annex A A.6.2.6 (operation and monitoring) and §10.1 (continual improvement) are partial anchors; EU AI Act Art. 72 post-market monitoring is related — it protects compliance, not value.
MANAGE MANAGE 2.4	Mechanisms exist to supersede, disengage, or deactivate AI systems performing inconsistently with intended use	§10.2 A.6.2.6 Partial	Art. 14 Art. 20 Direct	EU AI Act Art. 14(4)(e) requires the ability to interrupt or stop the system, and Art. 20 requires providers to take corrective actions — withdraw, disable, or recall non-conforming systems. ISO §10.2 (nonconformity and corrective action) plus Annex A A.6.2.6 are partial.
MANAGE MANAGE 3.1	AI risks and benefits from third-party resources are regularly monitored, with risk controls applied and documented	§9.1 A.10.3 Partial	Art. 25 Partial	Annex A A.10.3 (suppliers) plus §9.1 monitoring approximate third-party monitoring; EU AI Act Art. 25 allocates value-chain responsibilities but mandates no ongoing third-party monitoring.
MANAGE MANAGE 3.2	Pre-trained models used in development are monitored as part of regular monitoring and maintenance	A.6.2.6 A.10.3 Partial	Art. 25 Partial	Annex A A.6.2.6 (operation and monitoring) extends to model components and A.10.3 to their suppliers; EU AI Act Art. 25 covers reliance on third-party models and tools in the value chain. Neither framework names pre-trained models specifically.
MANAGE MANAGE 4.1	Post-deployment monitoring plans are implemented — user input, appeal and override, decommissioning, incident response	§9.1 A.6.2.6 Direct	Art. 72 Art. 73 Direct	ISO §9.1 and Annex A A.6.2.6 require operating-phase monitoring; EU AI Act Art. 72 requires a documented post-market monitoring plan and Art. 73 serious-incident reporting.
MANAGE MANAGE 4.2	Measurable continual-improvement activities are integrated into AI system updates, with engagement of interested parties	§10.1 Direct	Art. 43 Art. 72 Partial	ISO §10.1 is the continual-improvement clause. Under the EU AI Act, post-market monitoring (Art. 72) feeds improvement, and substantial modifications trigger renewed conformity assessment (Art. 43) — partial.

Crosswalk snapshot

Frameworks: 04
Mappings: 51
Posture: Aligned

Aligned and audit-ready, not certified. Includes TRAIGA (Texas HB 149) extension. Full expansion (230+ rows) tracked in CYT-124.

TRAIGA extension Texas HB 149

TRAIGA obligations, mapped to the same NIST AI RMF anchors.

The Texas Responsible Artificial Intelligence Governance Act (HB 149, effective January 1, 2026, enforced exclusively by the Texas Attorney General) mapped to the NIST AI RMF sub-categories this crosswalk already uses as its anchor taxonomy, so each TRAIGA obligation traces through those anchors to the ISO/IEC 42001 and EU AI Act mappings above. § 552.105(e) recognizes substantial compliance with NIST's AI RMF Generative AI Profile as a statutory defense, which is what grounds NIST-anchored mapping. The dataset includes 11 provisions, 10 mapped and 1 recorded gap.

TRAIGA (Texas HB 149) provisions mapped to NIST AI RMF sub-categories. Through those anchors, each row traces to the ISO/IEC 42001 and EU AI Act mappings in the main table.
TRAIGA (Tex. Bus. & Com. Code)	Obligation	NIST AI RMF anchor	Mapping note
§ 551.002 Applicability	The subtitle applies only to a person who: (1) promotes, advertises, or conducts business in Texas; (2) produces a product or service used by Texas residents; or (3) develops or deploys an AI system in Texas.	GOVERN 1.1 Direct	Determining whether you are a covered developer or deployer is the entry obligation; maps directly to RMF legal/regulatory-requirements management (GOVERN 1.1).
§ 552.051 Disclosure to consumers	A governmental agency that makes available an AI system intended to interact with consumers must disclose to each consumer, before or at the time of interaction, that the consumer is interacting with an AI system. The disclosure is required regardless of whether it would be obvious; must be clear and conspicuous, in plain language, and may not use a dark pattern; and a provider using AI in relation to a health-care service or treatment must give the disclosure no later than the date the service is first provided (in an emergency, as soon as reasonably possible).	MEASURE 2.8 Partial	RMF examines transparency/accountability risk; TRAIGA imposes a mandatory point-of-interaction disclosure, but only on governmental agencies and health-care contexts.
§ 552.052 Manipulation of human behavior	A person may not develop or deploy an AI system in a manner that intentionally aims to incite or encourage a person to commit physical self-harm (including suicide), harm another person, or engage in criminal activity.	MAP 1.1 MEASURE 2.6 Partial	Intent-based prohibition; intended-purpose/context documentation and safety evaluation are the interpretive anchors (Cytra's interpretation).
§ 552.053 Social scoring	A governmental entity may not use or deploy an AI system that evaluates or classifies persons based on social behavior or personal characteristics with the intent to assign a social score that results or may result in detrimental/unfavorable treatment in unrelated contexts, treatment unjustified or disproportionate to the observed behavior, or infringement of rights under the U.S. Constitution, Texas Constitution, or law.	MEASURE 2.11 Related	Binds governmental entities only; fairness evaluation is the nearest RMF discipline.
§ 552.054 Capture of biometric data	A governmental entity may not develop or deploy an AI system for uniquely identifying a specific individual using biometric data or targeted/untargeted gathering of images or other media from the Internet or other publicly available sources without the individual's consent, if the gathering would infringe the individual's constitutional or legal rights; a violation of Bus. & Com. Code § 503.001 is a violation of this section.	MEASURE 2.10 Related	Privacy-risk examination is the nearest anchor; duty binds governmental entities; § 503.001 violations count as violations of this section.
§ 552.055 Constitutional protection	A person may not develop or deploy an AI system with the sole intent for the system to infringe, restrict, or otherwise impair an individual's rights guaranteed under the U.S. Constitution.	GOVERN 1.1 Related	Narrow "sole intent" standard; legal-requirements management is the nearest hook — interpretive.
§ 552.056 Unlawful discrimination	A person may not develop or deploy an AI system with the intent to unlawfully discriminate against a protected class in violation of state or federal law; disparate impact alone is not sufficient to demonstrate intent; carve-outs exist for regulated insurance entities and federally insured financial institutions in compliance with banking law.	MEASURE 2.11 Partial	TRAIGA's prohibition is intent-based and disparate impact alone is insufficient; RMF fairness/bias evaluation is broader, and its measurement records are natural evidence of the absence of discriminatory intent.
§ 552.057 Certain sexually explicit content and child pornography	A person may not develop or distribute an AI system with the sole intent of producing or aiding production/distribution of visual material violating Penal Code § 43.26 or deep-fake videos/images violating Penal Code § 21.165, or intentionally develop/distribute a system engaging in text-based conversations that simulate or describe sexual conduct while impersonating or imitating a child younger than 18.	Gap	Categorical criminal-content prohibition with no meaningful RMF control counterpart; recorded as a gap rather than papered over.
§ 552.103 Civil investigative demands	On a complaint (via the § 552.102 online mechanism) the AG may issue a civil investigative demand (CID) requesting: a high-level description of the system's purpose, intended use, deployment context, and benefits; a description of the type of data used to program or train it; the categories of input data; the outputs produced; performance-evaluation metrics; known limitations; a high-level description of post-deployment monitoring and user safeguards (including a deployer's oversight, use, and learning process); and other documentation reasonably necessary.	MAP 1.1 MANAGE 4.1 Direct	The CID list (purpose, intended use, training data, inputs, outputs, metrics, limitations, post-deployment monitoring) reads like an RMF documentation index; intended-purpose documentation and post-deployment monitoring plans are the anchors.
§ 552.104 Notice of violation; opportunity to cure	The AG must give written notice identifying the specific provisions violated and may not bring an action before the 60th day after notice; no action if the person cures within 60 days and provides a written statement that they cured the violation, supporting documentation showing how, and internal-policy changes to reasonably prevent recurrence.	MANAGE 4.3 Partial	Documented incident tracking/response/recovery is what makes a 60-day cure demonstrable with supporting documentation.
§ 552.105 Civil penalty; statutory defenses	Uncured violations: $10,000–$12,000 per curable violation (or breach of a cure statement), $80,000–$200,000 per uncurable violation, $2,000–$40,000 per day for continuing violations; rebuttable presumption of reasonable care; a defendant may not be found liable if the violation was discovered through feedback, adversarial or red-team testing, following applicable state-agency guidelines, or substantial compliance with the most recent version of the "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile" published by NIST or another nationally or internationally recognized AI risk-management framework.	GOVERN 1.2 MEASURE 2.7 Direct	§ 552.105(e) recognizes substantial compliance with the most recent NIST AI RMF Generative AI Profile (or another recognized AI risk-management framework) and adversarial/red-team testing as defenses — TRAIGA's strongest NIST hook; trustworthy-AI policy integration and security/red-team evaluation anchor it.

Posture: Cytra is aligned, not certified. Mapping strengths and notes are Cytra's interpretation with uncertain or scope-limited mappings marked in the notes. Informational summary of TRAIGA as enacted, not legal advice — consult counsel.

TRAIGA readiness (Texas HB 149)

Next step turn the crosswalk into runtime evidence

Map the controls once. Let the gateway generate the evidence.

Cytra Gateway, our managed MCP gateway, routes every AI agent action through the same control objectives this crosswalk describes and produces continuous, tamper-evident evidence — mapped to NIST AI RMF, ISO/IEC 42001, and the EU AI Act — rather than a document assembled after the fact. Currently in private beta.

The CARGO framework lens Request early access