We treat third-party AI as a dual supply chain: a supply chain for the software components and a supply chain for the data and model behavior. SBOMs? That's the easy part. We do vulnerability scanning in our CI/CD pipeline to check the model's underlying libraries just like we scan any other dependency. Model cards are a different nut to crack--they're a governance gate, not just a technical one. The Aspen Institute says this well: A model card "defines the model's intended readers and the lens from which the authors want them to understand the model". The artifact that caught a material issue for us wasn't a scanner, but a policy. We were evaluating a third-party NLP model to be exposed to a customer-facing feature. The SBOM was clean. Our internal policy says that our team will manually review the data provenance section of a model card. In that review, our team discovered that the model had been trained on a publicly scraped dataset that we knew with high confidence to have contain personally identifiable information that would violate our client's data residency. The model had memorized this sensitive data. Rejecting that model saved us from a significant privacy and compliance incident before it actually made it to the staging environment.
We kept it lightweight and practical instead of academic. Every third-party model or dataset had to ship with two things before use: a basic SBOM listing dependencies and data sources, and a short model card answering how it was trained, known limitations, and intended use. Nothing fancy, just enough to force clarity. The check that actually caught a real issue was a simple question in the model card: "What data should this model not be used with?" That surfaced a licensing restriction tied to a dataset that conflicted with our use case. We caught it before deployment and avoided a messy rollback later. The lesson was that simple, mandatory artifacts beat complex frameworks that no one consistently follows.