74. AI System Bill of Materials (AI‑SBOM) Explained: How to Document AI Supply Chains (Models, Data, Tools) + a Practical Checklist

Last Updated: May 8, 2026

Every piece of software your organization runs is built from components — libraries, frameworks, APIs, and third-party modules assembled into something that serves a business purpose. The software supply chain attack vector — exploiting vulnerabilities in these underlying components to compromise the systems built on top of them — has been one of the most consequential cybersecurity threat categories of the past decade. The SolarWinds attack, the Log4Shell vulnerability, the XZ Utils backdoor — each demonstrated that the most dangerous vulnerabilities are often not in the code your organization writes but in the components your code depends on. The Software Bill of Materials (SBOM) — a structured inventory of every component in a software system — emerged as the primary defense: you cannot protect what you cannot see, and you cannot see what you have not documented.

AI systems are software systems — but they introduce supply chain complexity that goes significantly beyond what conventional SBOMs were designed to address. A conventional software application’s supply chain consists of code dependencies — libraries and modules that can be enumerated, versioned, and vulnerability-scanned using established tools. An AI system’s supply chain includes all of that plus an entirely additional category of components that have no equivalent in conventional software: the foundation models whose weights determine behavior, the training datasets whose characteristics determine bias and accuracy, the fine-tuning data that shapes the model’s domain-specific capabilities, the retrieval augmentation knowledge bases that provide factual context, and the tool integrations that determine what the system can do in the world. An SBOM that covers only the code dependencies of an AI application has documented perhaps 20% of its actual supply chain risk surface.

The AI System Bill of Materials (AI-SBOM) — sometimes called an AI-BOM or an AI component inventory — is the documentation standard designed to address this gap: a structured inventory that covers not just the code dependencies of an AI application but every component in its complete supply chain, from the foundation model through the training data through the deployment infrastructure. According to NIST’s AI security research, organizations that maintain comprehensive AI-SBOMs are significantly better positioned to respond to AI supply chain incidents — identifying affected systems faster, assessing impact more accurately, and communicating with stakeholders more effectively than those relying on incomplete or informal component documentation. This guide provides everything you need to understand, create, and operationalize AI-SBOMs for every AI system your organization deploys.

1. 🧩 What Is an AI-SBOM and Why Does It Exist?

An AI System Bill of Materials is a structured, machine-readable inventory of every component that contributes to an AI system’s behavior — including models, datasets, code dependencies, tool integrations, infrastructure components, and third-party services. The term “Bill of Materials” is borrowed from manufacturing, where a BOM is the complete list of every part, component, and raw material that goes into a finished product. In AI, the AI-SBOM serves the same function: it makes the complete composition of an AI system visible, traceable, and auditable in a standardized format that can be shared with stakeholders, evaluated by auditors, and queried by security tools.

The Supply Chain Visibility Problem AI Systems Create

The fundamental problem that AI-SBOMs address is supply chain opacity — the invisibility of AI system components to the organizations that deploy them and the individuals and regulators affected by their outputs. When an organization deploys a conventional software application, the application’s behavior is fully determined by its code — code that can be read, audited, tested, and understood by humans with appropriate technical expertise. When an organization deploys an AI system, the system’s behavior is substantially determined by its model weights — billions of numerical parameters that encode the patterns learned from training data. Those weights are typically not readable or auditable in any meaningful sense. The behavior they produce depends critically on the characteristics of the training data that generated them — data that the deploying organization almost certainly did not produce and may know very little about.

This opacity creates a supply chain risk that is qualitatively different from conventional software supply chain risk. A vulnerability in a code library can be identified by scanning the library against a vulnerability database and remediated by updating to a patched version. A bias introduced through training data cannot be identified by scanning the model weights — it can only be discovered through behavioral testing, and remediation may require retraining on different data or applying post-processing corrections. An AI-SBOM does not eliminate these risks, but it makes them visible — providing the component-level information needed to identify which AI systems are affected when a training data problem is discovered, which systems depend on a foundation model that has been identified as having specific limitations, and which systems use data sources whose licensing or privacy status has changed.

The Regulatory Catalyst

The emergence of AI-SBOM as a formal documentation requirement — rather than a best practice recommendation — has been substantially driven by three regulatory developments in 2025 and 2026. The EU AI Act’s technical documentation requirements for high-risk AI systems explicitly require documentation of training data and model characteristics that AI-SBOM provides. The US Executive Order on AI Safety (October 2023) directed federal agencies to develop standards for AI transparency that include component documentation. And NIST’s COSAiS overlay — which we cover in our guide to NIST COSAiS — requires AI-SBOM as a specific Supply Chain Risk Management control for AI systems within the SP 800-53 framework. Together, these regulatory developments have moved AI-SBOM from an emerging concept to an actively enforced documentation requirement for organizations deploying AI in regulated contexts.

The Core Analogy: Think of an AI-SBOM the way you think of a nutrition label on food packaging. The nutrition label does not tell you whether a specific food item is safe for a specific person — it tells you exactly what is in it so that the person can make that determination for themselves. An AI-SBOM does not tell you whether a specific AI system is safe for a specific use case — it tells you exactly what the system is made of so that the deploying organization, its regulators, and its auditors can make that determination with full information rather than partial knowledge.

2. 📋 The Seven Component Categories of a Complete AI-SBOM

A complete AI-SBOM covers seven distinct component categories that together constitute the complete supply chain of an AI system. Each category carries distinct risk dimensions, requires different documentation approaches, and connects to different regulatory requirements. Omitting any category produces an incomplete supply chain picture that will miss significant risk exposures.

Category 1: Foundation Model Components

For AI systems built on foundation models — which in 2026 means virtually every LLM-based application — the foundation model is the most consequential component in the supply chain. Foundation model documentation in an AI-SBOM should cover: the model name and version, the provider organization, the model architecture type, the documented training data sources (at the level of granularity the provider discloses), the model’s training cutoff date, the license under which the model is made available, any known limitations or documented failure modes from the provider’s model card, the API endpoint or deployment mechanism through which the model is accessed, and the version stability guarantees provided by the model provider.

Version stability documentation deserves particular emphasis. Foundation model providers — including OpenAI, Anthropic, Google, and Meta — update their models regularly, and those updates can change model behavior in ways that affect the downstream AI application’s performance, safety properties, and compliance status. An AI-SBOM that documents only the model family name (e.g., “GPT-4”) without the specific version deployed provides insufficient traceability — because different versions of the same model family may have meaningfully different characteristics. Organizations should document the specific model version they have tested and validated, and establish a change control process for approving model version updates before they are deployed to production.

Category 2: Fine-Tuning and Adaptation Components

Many AI systems are not deployed on top of a raw foundation model — they use a foundation model that has been fine-tuned on domain-specific data or adapted through techniques like Reinforcement Learning from Human Feedback (RLHF), Constitutional AI, or Direct Preference Optimization (DPO). When fine-tuning has been applied, the AI-SBOM must document the fine-tuning methodology, the fine-tuning dataset (including its source, composition, size, and any known quality issues), the fine-tuning infrastructure and compute used, the validation methodology applied to the fine-tuned model, and any alignment or safety training applied during or after fine-tuning.

For organizations using Parameter-Efficient Fine-Tuning (PEFT) techniques like LoRA adapters, the AI-SBOM should document the adapter configuration separately from the base model — because the adapter represents a distinct, replaceable component that may need to be updated independently of the base model. Organizations that fine-tune models on proprietary data and then deploy those models must also document the data governance status of the fine-tuning data — particularly whether the data contains personal information that subjects the fine-tuned model to data protection obligations.

Category 3: Training and Retrieval Data Components

The data components of an AI-SBOM represent the highest-complexity documentation challenge — because AI systems can be influenced by dozens of distinct data sources with different provenance, licensing, and quality characteristics. For systems using Retrieval-Augmented Generation (RAG), the knowledge base documents and their sources must be documented as components. For systems using custom training data, the datasets and their characteristics must be documented using the Datasheets for Datasets framework covered in our training data documentation guide.

Data component documentation should address: the source of each data component, the collection methodology, the date range of the data, any preprocessing or filtering applied, the license under which the data is used, any known quality issues or biases, the demographic composition of the data where relevant, and whether the data contains personal information that creates ongoing data protection obligations. For RAG knowledge bases specifically, the AI-SBOM should document the knowledge base update schedule — because a RAG system’s factual accuracy depends on the currency of its knowledge base, and stale knowledge base content is a documented source of AI system accuracy degradation.

Category 4: Code and Software Dependency Components

This is the component category that conventional SBOMs already address — the code libraries, frameworks, and modules that the AI application is built with. For AI systems, the relevant code dependencies include both the general application framework dependencies and the AI-specific dependencies: machine learning frameworks like PyTorch or TensorFlow, inference libraries, model serving frameworks, vector database clients, embedding libraries, and agent orchestration frameworks like LangChain, LangGraph, or AutoGen.

The conventional SBOM formats — CycloneDX and SPDX — handle this component category well, and organizations that already produce conventional SBOMs for their software applications can extend those SBOMs with the additional AI-specific component categories rather than creating a completely separate document. This integration approach — extending rather than duplicating — is the most efficient path to comprehensive AI-SBOM coverage for organizations that already have mature software supply chain documentation practices. Our guide to the OWASP AIBOM Generator covers the tooling that automates the generation of CycloneDX-format AI-SBOMs including the AI-specific component categories.

Category 5: Tool Integration and API Components

For agentic AI systems that connect to external tools and APIs through protocols like the Model Context Protocol (MCP), the tool integrations represent a critical supply chain component category. Each tool integration is a dependency — a component that the AI system relies on to function as designed, that may have its own vulnerabilities and supply chain risks, and that represents a potential attack surface for prompt injection and unauthorized action.

Tool integration documentation in an AI-SBOM should cover: the tool or API name and provider, the version or API version, the authentication mechanism used, the specific permissions granted to the AI system through this integration, the data types that flow through the integration, any rate limits or cost constraints, and the security controls in place to prevent the integration from being exploited. For organizations deploying agents with broad tool access, this component category will often be the largest and most dynamic section of the AI-SBOM — because tool integrations change more frequently than model versions or training datasets, and maintaining an accurate tool integration inventory requires ongoing operational discipline.

Category 6: Infrastructure and Deployment Components

The infrastructure on which an AI system runs is a component with its own supply chain risk profile. Infrastructure documentation in an AI-SBOM should cover: the cloud provider and specific services used for model inference, the geographic regions in which data is processed (relevant to data sovereignty requirements), the container and orchestration technology, any specialized AI inference hardware, the content delivery and caching infrastructure, and the network security components that protect AI system communications.

Infrastructure documentation is particularly important for organizations subject to data sovereignty requirements — GDPR’s restrictions on cross-border data transfers, US government requirements for data processing within US jurisdiction, or industry-specific data residency requirements in healthcare and financial services. An AI-SBOM that documents the geographic location of every infrastructure component provides the evidence that compliance teams need to demonstrate data residency compliance without relying on vendor assurances alone.

Category 7: Third-Party AI Service Components

Many AI systems incorporate third-party AI services — specialized models, AI APIs, or AI-powered SaaS features — as components of a larger AI application architecture. An embedding API that converts text to vectors, a speech-to-text service that transcribes user audio, a content moderation API that filters AI outputs, or an AI-powered translation service that handles multilingual interactions are all third-party AI service components that carry their own supply chain risk profiles and must be documented as distinct components in the AI-SBOM.

Third-party AI service components are among the highest-risk items in the AI supply chain because they are often the least visible. Organizations frequently adopt these services as implementation conveniences without fully assessing their data handling practices, their compliance status, or their vulnerability to the AI-specific attack vectors that their embedded role in the system creates. The AI vendor due diligence framework should be applied to every third-party AI service component documented in the AI-SBOM — not just to the primary AI platform vendor.

3. 📐 AI-SBOM Formats: CycloneDX and SPDX

Machine-readable AI-SBOMs are produced in standardized formats that allow automated tools to parse, query, and compare component inventories across systems. Two formats dominate the SBOM ecosystem in 2026 — CycloneDX and SPDX — and both have been extended to support AI-specific component types.

CycloneDX: The Recommended Format for AI-SBOMs

CycloneDX is the SBOM format developed by OWASP — the same organization responsible for the OWASP Top 10 security risk lists. CycloneDX has become the preferred format for AI-SBOMs for three reasons. First, it has the most mature AI-specific extension support — CycloneDX version 1.5 and later include dedicated component types for machine learning models, datasets, and AI services that allow AI-specific metadata to be captured in a structured, standardized way. Second, it is the format supported by the OWASP AIBOM Generator tool — the most widely used open-source tool for generating AI-SBOMs from existing AI system configurations. Third, CycloneDX’s hierarchical component structure naturally represents the nested dependency relationships of AI systems — a foundation model that depends on training data that depends on data sources — in a way that flat component lists cannot.

A CycloneDX AI-SBOM includes standard SBOM metadata — document creation date, document author, the AI system being documented — followed by a components section that lists each component with its type, name, version, supplier, license, and any type-specific metadata. For ML model components, CycloneDX supports metadata fields for model type, intended use, training data references, and model card references. For dataset components, it supports fields for data type, collection methodology, and license status. This structured metadata makes CycloneDX AI-SBOMs actionable for security tooling — automated tools can parse the structured metadata to identify components affected by newly disclosed vulnerabilities or licensing issues without requiring human reading of each document.

SPDX: The ISO Standard Format

SPDX (Software Package Data Exchange) is the SBOM format maintained by the Linux Foundation and published as ISO/IEC 5962 — the only SBOM format with ISO standardization. SPDX 3.0, released in 2024, includes AI and dataset profile extensions that support AI-specific component documentation. For organizations where ISO standardization is a formal requirement — particularly in government procurement contexts and in European markets where ISO standards carry regulatory weight — SPDX provides the format with the strongest standards pedigree.

Organizations choosing between CycloneDX and SPDX for their AI-SBOM program should consider: the tooling ecosystem they are already using (most AI security tools have better CycloneDX support), the regulatory context they are operating in (SPDX’s ISO status may be advantageous in some regulatory submissions), and whether they are extending an existing conventional SBOM program (maintaining format consistency with existing SBOMs reduces tooling complexity). Both formats are machine-readable, both support AI-specific extensions, and both can satisfy the AI-SBOM requirements of major regulatory frameworks — the choice between them is primarily an operational and ecosystem consideration rather than a fundamental governance decision.

4. 🔬 Creating Your First AI-SBOM: A Practical Step-by-Step Process

The process of creating an AI-SBOM for an existing AI system — one that was deployed without systematic component documentation — is more involved than creating one for a new system during its development. The following process is designed for the retroactive documentation case that most organizations face in 2026: they have AI systems in production, those systems lack comprehensive component documentation, and they need to create that documentation to satisfy regulatory, audit, or procurement requirements.

Step 1: AI System Inventory and Scoping

Before creating AI-SBOMs, you need to know what AI systems you are creating them for. Conduct a systematic inventory of every AI system in your organization’s production environment — including AI features embedded in conventional software platforms that may not be tracked in your primary application inventory. Shadow AI discovery tools can identify AI systems and APIs being used across the organization’s network that are not tracked in any formal inventory. The output of this step is a prioritized list of AI systems requiring AI-SBOM documentation, ranked by risk level — systems used in high-stakes decisions or handling sensitive data should be prioritized for immediate documentation.

Step 2: Component Discovery for Each System

For each AI system in scope, conduct a structured component discovery exercise that systematically identifies every component in each of the seven categories. This discovery process involves interviewing the teams that built and maintain each system, reviewing technical documentation, examining deployment configurations, auditing API integrations, and reviewing data pipeline documentation. For systems where institutional knowledge about component provenance is incomplete — because the team that built the system has turned over or because the system was procured as a pre-built solution — vendor documentation requests may be needed to fill gaps.

Component discovery is often the most time-consuming step in AI-SBOM creation for legacy systems — not because the documentation is technically difficult to produce, but because the information required to produce it is often distributed across multiple teams, systems, and documentation sources that have never been consolidated. Building this consolidated picture for the first time reveals both the complete component inventory and the knowledge gaps that represent ongoing supply chain risk.

Step 3: Document Each Component with Required Metadata

For each discovered component, document the required metadata fields for its category. The level of detail achievable will vary — foundation model providers like OpenAI and Anthropic publish detailed model cards that provide most of the required metadata, while smaller or proprietary model providers may have limited public documentation that requires supplementation through vendor due diligence requests. Document what is known and explicitly flag what is unknown — an AI-SBOM that clearly identifies documentation gaps is more valuable than one that silently omits unknown information.

Step 4: Generate the Machine-Readable SBOM Document

Once the component inventory and metadata are documented, generate the machine-readable AI-SBOM in CycloneDX or SPDX format. For organizations with existing SBOM tooling, most modern SBOM generation tools can be extended with AI component templates that capture AI-specific metadata fields. The OWASP AIBOM Generator provides a purpose-built tool for generating CycloneDX AI-SBOMs from AI system configurations with guided workflows for each component category. Manual generation using the CycloneDX JSON schema is also feasible for organizations with small AI system portfolios and existing JSON tooling capability.

Step 5: Review, Validate, and Baseline

Review the generated AI-SBOM against the actual system configuration to verify accuracy — every component listed in the SBOM should correspond to a component actually present in the deployed system, and every component present in the deployed system should appear in the SBOM. Establish the validated SBOM as the baseline for the system — the documented state from which future changes will be tracked. Integrate AI-SBOM updates into the change control process for the system so that every component change — model version update, knowledge base refresh, tool integration addition — triggers a corresponding SBOM update.

Step 6: Register in the Organization’s AI Component Registry

Individual AI-SBOMs are most valuable when they are part of an organizational AI component registry — a searchable database of all AI-SBOM data across all AI systems in the organization. This registry enables cross-system queries: “Which of our AI systems use this specific model version?” or “Which of our AI systems have training data from this provider?” are questions that can only be answered efficiently if AI-SBOM data is consolidated in a queryable registry rather than existing as individual documents per system. The registry also provides the organizational-level visibility that executive leadership, compliance teams, and security operations centers need to manage AI supply chain risk at scale.

5. 🔗 AI-SBOM in the Regulatory and Compliance Landscape

Understanding how AI-SBOM connects to the specific regulatory requirements that organizations must satisfy helps compliance leaders prioritize AI-SBOM investment and communicate its value to stakeholders who may view it as a technical documentation exercise rather than a compliance necessity.

6. 🔄 Maintaining AI-SBOMs: The Ongoing Operational Challenge

Creating an AI-SBOM is a significant accomplishment — but it is only the beginning of the operational discipline that AI-SBOM programs require. AI systems are not static: models are updated, training data is refreshed, tool integrations are added and modified, infrastructure is migrated, and third-party services change their terms and capabilities. An AI-SBOM that accurately describes an AI system at the point of creation will become inaccurate — and therefore misleading as a governance artifact — if it is not maintained as the system evolves.

Integrating AI-SBOM Updates into Change Control

The most effective mechanism for maintaining AI-SBOM accuracy is treating SBOM updates as a mandatory step in the change control process for every AI system component — not as a separate documentation task that competes with operational priorities. When a model version is updated, the AI-SBOM is updated as part of the update approval process. When a new tool integration is added, the AI-SBOM is updated as part of the integration deployment process. When a RAG knowledge base is refreshed with new documents, the AI-SBOM is updated as part of the refresh workflow. This integration of SBOM maintenance into operational change control ensures that the SBOM reflects the current state of the system at all times — not a historical snapshot that diverges from reality over time.

Automated SBOM Monitoring for Component Changes

For components that can be monitored programmatically — foundation model APIs, code dependencies, and infrastructure components — automated monitoring tools can detect component changes and flag them for SBOM update review. Model version change detection — alerting when an API endpoint returns a different model version header than the documented version — is a particularly important automated monitoring use case because foundation model providers do not always provide advance notice of silent model updates that change behavior without changing the model family name. Automated dependency scanning that detects updates to code dependencies and compares them against the documented SBOM versions provides the same kind of continuous accuracy assurance for the code dependency component category that is already standard practice in mature DevSecOps programs.

Periodic Comprehensive Review

In addition to change-triggered updates, AI-SBOMs should undergo periodic comprehensive review — at least annually — that independently verifies the SBOM’s accuracy against the actual deployed system configuration rather than relying solely on change-triggered updates. This periodic review catches components that changed through processes that did not trigger the formal change control process — shadow IT integrations, informal experiments that became production dependencies, and vendor-side changes to third-party services that the consuming organization did not track. The periodic review is the AI-SBOM equivalent of a physical inventory audit — it catches the discrepancies that continuous monitoring misses.

7. ⚠️ Common AI-SBOM Implementation Mistakes

Organizations implementing AI-SBOM programs for the first time consistently make a predictable set of mistakes that reduce the governance value of the program and create compliance exposure. Understanding these mistakes in advance allows organizations to avoid them rather than discovering them during an audit or incident.

Mistake 1: Treating AI-SBOM as a Code-Only Document

The most common AI-SBOM mistake is producing a document that covers only the code dependency component category — effectively a conventional SBOM — and calling it an AI-SBOM. This mistake produces a document that satisfies the literal request for an AI-SBOM while missing the components that are most consequential for AI-specific supply chain risk: the foundation models, training datasets, and tool integrations that conventional SBOMs were never designed to cover. Auditors and regulators who are familiar with AI-SBOM requirements will immediately identify this gap during review.

Mistake 2: Documenting Model Family Names Without Version Specificity

Documenting “GPT-4” as a foundation model component rather than the specific API version endpoint being used is a common documentation shortcut that eliminates the traceability value of the model documentation. When a vulnerability or behavioral issue is identified in a specific model version, organizations need to determine quickly whether their deployed system uses the affected version. A model family name without version specificity makes this determination impossible — every AI system that references “GPT-4” must be manually investigated rather than being identified through a simple registry query.

Mistake 3: Creating AI-SBOMs as Static Documents

An AI-SBOM that is created once and never updated is worse than no AI-SBOM at all — because it creates a false sense of supply chain visibility while the actual supply chain diverges from the documented state. AI-SBOMs must be living documents that evolve with their systems. Organizations that do not integrate AI-SBOM maintenance into their change control processes will consistently find their SBOMs drifting from reality — a situation that is discovered, expensively, during audits or incidents when the SBOM’s inaccuracy is most consequential.

Mistake 4: Omitting Unknown Information Instead of Documenting Uncertainty

When component information is genuinely unknown — because a third-party vendor has not disclosed their training data sources, because a legacy system’s provenance has been lost, or because a tool integration was added informally — the appropriate response is to document the uncertainty explicitly rather than omitting the component or fabricating plausible-sounding information. An AI-SBOM with clearly documented knowledge gaps — “training data sources: undisclosed by vendor; vendor disclosure request pending” — is a more accurate and more useful governance artifact than one that presents incomplete information as if it were complete.

8. 🏁 Conclusion: AI-SBOM as the Foundation of AI Supply Chain Trust

The AI-SBOM is not a documentation exercise — it is the technical foundation of AI supply chain trust. Every other AI governance capability — bias assessment, security testing, compliance demonstration, incident response — depends on having an accurate, current inventory of what an AI system is made of. You cannot assess the bias risk of training data you have not documented. You cannot respond effectively to a foundation model supply chain incident if you do not know which of your systems use the affected model. You cannot demonstrate regulatory compliance with training data requirements if you cannot produce evidence of what your training data was. The AI-SBOM is the prerequisite for all of it.

The regulatory momentum behind AI-SBOM is clear and accelerating — EU AI Act enforcement is active, NIST COSAiS requirements are being referenced in federal procurement, and enterprise clients are incorporating AI-SBOM requests into their vendor evaluation processes with increasing frequency. Organizations that have built systematic AI-SBOM capability are ahead of these requirements, better positioned to respond to supply chain incidents, and better equipped to demonstrate the supply chain transparency that responsible AI deployment demands. Organizations that have not started are accumulating a documentation debt that will become increasingly expensive to address as regulatory requirements tighten and as the complexity of their AI system portfolios grows.

Start with your highest-risk AI system. Document all seven component categories to the best of your current knowledge. Flag the gaps honestly. Integrate the documentation into your change control process. Build toward a machine-readable format. And connect your AI-SBOM program to the broader AI governance ecosystem — the dataset documentation, the model cards, the system cards, and the risk assessments — that together constitute a complete AI transparency infrastructure. The AI supply chain is real, it is consequential, and it is increasingly visible to the regulators and auditors who oversee it. Build the documentation that makes it visible to you first.

📌 Key Takeaways

🔗 Related Articles

• 📖 Datasheets for Datasets Explained: How to Document AI Data for Quality and Trust
• 📖 AI Model Cards Explained: How to Document an AI System for Transparency and Trust
• 📖 OWASP AIBOM Generator Explained: How to Create an AI-SBOM in CycloneDX Format
• 📖 NIST COSAiS Explained: SP 800-53 Control Overlays for Securing AI Systems
• 📖 AI Vendor Due Diligence Checklist: How to Evaluate AI Tools Before You Share Data