A mid-size firm racing a fee proposal dropped the owner's confidential energy model and a partial set of structural calculations into a free AI tool to summarize them, because the deadline was tight and the tool was right there in the browser. The tool's terms, the ones nobody on the team had read, granted the vendor a license to use submitted content to improve its models, and there was no enterprise tenancy, no training opt-out, no data residency commitment. The owner's confidential design data, which the firm did not own and was contractually bound to protect, had now been ingested into a system that trained on it, with no way to claw it back. The cost was not a fine in the mail; it was a confidentiality breach the firm could not undo, discovered only when the owner's counsel asked which tools had touched their model. As the firm's AI strategist and the risk owner who signs the enterprise AI contract, your job is to make sure that moment never happens by running real diligence before the signature, not after the breach. By the end of this lesson you will be able to produce the diligence checklist for an enterprise AI contract: the security, data, IP, and governance questions that protect the owner data you hold and the model IP you do not own.

Why Diligence Precedes the Signature, Not the Breach

The opening scene is expensive precisely because it was avoidable. The breach required no sophisticated attacker or clever exploit; it required only that a team used a tool whose terms they had not read, on data they were not free to expose. The diligence that would have prevented it is not exotic, and not the procurement team's box-checking. It is the deliberate examination, before signature, of how a vendor secures data, what it does with the data you put in, who owns the model artifacts the tool produces, and whether the vendor's own AI governance is mature enough to trust. The discipline is that diligence precedes the signature, because once the contract is signed and the data flows, the questions you did not ask become risks you cannot retract.

This is the same posture the program has taught throughout, applied to the vendor relationship rather than a single deliverable. The cardinal rule has always been to verify before you commit: before you stamp, before you schedule, before you submit the pay app, before you adopt the safety plan. Here the commitment is the contract and the verification is the diligence. A firm signing an enterprise AI contract commits its owner data and model IP to a third party's systems and terms, and the verification gate is not a feeling that the vendor seems reputable; it is a set of named questions answered with named evidence, which is what the diligence checklist is.

The controlling analogy for the whole lesson is the building envelope. A good envelope is not one thick wall; it is a system of layers, each doing a specific job, structural, weather, thermal, vapor, air, and a failure in any one compromises the whole assembly even if the others are perfect. Enterprise AI diligence is the same layered envelope: a security layer, a data layer, an IP layer, and a governance layer, each protecting against a distinct failure mode, and a gap in any one is a path for the failure the opening scene illustrated. You do not get to skip a layer because the others look strong. The checklist is the envelope detail: which layer does what, and how you confirm each is continuous.

The Security Layer: SOC 2 Type II and ISO 27001

The security layer asks a single question with rigor: can this vendor be trusted to hold data securely, and what independent evidence proves it. The two artifacts that answer it, in complementary ways, are SOC 2 Type II and ISO 27001. A SOC 2 Type II report is an independent auditor's examination of whether the vendor's controls, covering security and often availability, confidentiality, processing integrity, and privacy, are not only designed appropriately but operated effectively over a period, typically six to twelve months. The Type II distinction matters: a Type I report attests only that controls are designed well at a point in time, while a Type II report tests that they actually worked across the audit window, the difference between a vendor saying it locks the doors and an auditor confirming the doors were locked every night for a year.

ISO 27001 is the other half, a certification that the vendor operates a formal information security management system, an ISMS, against an internationally recognized standard, with a defined scope, a risk assessment, a set of controls, and a surveillance audit cycle that keeps the certification live. SOC 2 is the report you read in detail to understand the specific controls and exceptions the auditor noted; ISO 27001 is the certificate that a managed, audited security program exists at all. The diligence move is not to accept the logo on the vendor's website but to obtain and read the actual SOC 2 Type II report under NDA, check that its scope covers the product you are buying and not some unrelated corporate system, confirm the audit period is current, and read the exceptions, because an unqualified report with a long list of noted exceptions is not the clean bill of health the logo implies.

The security layer also extends past the certifications to operational specifics the report should let you confirm: encryption in transit and at rest, access controls and least-privilege administration, logging and incident response, subprocessor management, and a breach notification commitment with a defined timeline. The failure mode here is the quiet assumption that a certified vendor has handled everything; certification narrows the risk but does not eliminate the need to confirm the specific protections your owner data requires are in scope. The security layer is the structural layer of the envelope: if it fails, nothing else matters.

The Data Layer: Residency, Training Opt-Out, and Owner Data

The data layer is the one the opening scene failed, and the layer most specific to AI. It asks three distinct questions. First, data residency: where, geographically, is your data stored and processed, because owner contracts, government work, and some international projects impose residency requirements, and a vendor that processes in a region you are not permitted to use is a contractual problem before anything else. The checklist asks the vendor to name the regions, commit to them contractually, and disclose any subprocessors that move data across borders, because residency you cannot pin down is residency you cannot promise your owner.

Second, the question the opening scene turned on, the model-training opt-out. The default behavior of many consumer and even some enterprise AI tools is to use the content you submit to improve the vendor's models, which means your project data, and the owner data inside it, becomes training data that shapes a model you do not control and cannot retrieve from. The diligence requirement is an explicit, contractual commitment that your project data does not train the vendor's model, ideally the default for the enterprise tenancy and confirmed in the contract language, not buried in a settings toggle a junior staffer can flip. This single clause is the difference between the opening scene and a safe deployment: with it, the owner's model stays the owner's; without it, it feeds a system you cannot reach.

Third, owner data handling across its lifecycle: how the data is segregated by tenant, how long it is retained, how it is deleted on request and at contract termination, and whether you receive confirmation of deletion. This matters because the firm is almost never the owner of the data it processes; the data belongs to the owner, and the firm holds it under a confidentiality obligation, passing a duty it owes to a third party. The data layer is the air barrier of the envelope: invisible when it works, the source of the most insidious failures when it has a gap, because the data leaks without anyone seeing it leave, exactly as the confidential model did in the opening scene. This ties to the L1 lesson on IP and confidentiality: the firm protects data it does not own, and the data layer is that principle written into the vendor contract.

Enterprise AI diligence is a layered envelope: security (independent proof the vendor holds data safely), data (residency, a contractual training opt-out so your project data does not train the vendor's model, and owner-data lifecycle handling), IP (model and BIM rights under AIA E203 and G202), and governance (NIST AI RMF alignment). A gap in any one layer is a path to the breach, because the firm is protecting owner data it does not own and model IP it does not own, and a signature cannot be retracted once the data flows.

The IP Layer: BIM and Model Rights Under AIA E203 and G202

The IP layer protects the rights in the digital models and data the AI touches, and in the AEC context those rights are governed by a framework that predates AI and now must accommodate it. AIA E203 is the Building Information Modeling and Digital Data Exhibit, which establishes at the project level that the parties will use BIM and digital data and sets the protocols for how. It is paired with AIA G202, the Project Building Information Modeling Protocol Form, which gets specific: it defines the level of development (the LOD framework the program has referenced, LOD 100 through 500) of model elements at each phase, assigns authorship and responsibility for each element, and governs the permitted uses and rights in the model content.

This matters because an AI tool ingests, transforms, and sometimes generates model and digital data, and who owns the inputs and outputs has to be reconciled with what E203 and G202 already say. The model content the firm puts into the tool is governed by the project's E203 and G202 terms, including the permitted uses and authorship the protocol assigns, so the AI vendor's contract cannot grant rights exceeding what the firm itself holds under the project documents. The diligence question is whether the vendor's terms respect that framework, or instead claim ownership or a broad license over submitted content or AI-generated derivatives in ways that conflict with the rights E203 and G202 establish for the project parties.

This is the layer where the firm protects model IP it does not own, the mirror image of the data layer. The firm is a steward of model content whose authorship and rights are distributed among the owner, the architect, the engineers, and the trades under the project's digital-data protocols, and it cannot, by signing an AI vendor contract, give away rights that belong to those parties. The checklist therefore asks the vendor to disclaim ownership of submitted model content, limit any license strictly to providing the service, assign or leave with the firm the rights in any AI-generated outputs, and confirm none of this conflicts with E203 and G202. The IP layer is the weather barrier of the envelope: it keeps those rights from being eroded by terms that look harmless until a dispute makes the ownership question expensive.

The Governance Layer: NIST AI RMF Alignment

The governance layer asks whether the vendor's own AI program is mature and trustworthy, not just secure. Security tells you the data is held safely; governance tells you the AI itself is built and operated responsibly, because a perfectly secure system can still embed a model that is biased, opaque, untested, or operated without accountability. The reference framework is the NIST AI Risk Management Framework, the AI RMF, a voluntary US framework structured around four functions, Govern, Map, Measure, and Manage, describing how an organization should identify, assess, and mitigate the risks of an AI system across its lifecycle. It is the responsible-AI thread the program has carried, expressed as a vendor-diligence standard.

Alignment with the NIST AI RMF is not a certification you can demand the way you demand a SOC 2 report, because the framework is voluntary and descriptive rather than certifiable, so the diligence move is to ask the vendor to describe how its AI program maps to the four functions. Under Govern, does it have AI policies, accountable roles, and a risk culture. Under Map, does it document the contexts and intended uses of its system and the risks those create. Under Measure, does it test for performance, bias, robustness, and the failure modes that matter. Under Manage, does it prioritize and act on the risks it identifies, with monitoring and incident response. A vendor that answers these in specifics has a real AI governance program; one that answers in marketing language does not.

The governance layer connects the vendor's maturity to the firm's own responsible-AI obligations, because the firm's verification gates and its accountability for AI-assisted work assume the underlying tool behaves predictably and can be reasoned about. A vendor aligned to the NIST AI RMF gives the firm the documentation it needs to know how the model was tested and where it is weak, which is what lets the firm's professionals verify AI output responsibly rather than trusting a black box. The governance layer is the thermal layer of the envelope: less visible than the structure, but the layer that determines whether the whole assembly performs as designed over time.

The Applied Problem: Produce the Diligence Checklist

Here is the exercise. Produce the diligence checklist for an enterprise AI contract, organized as the four-layer envelope, each layer a set of named questions paired with the named evidence that answers it, so the strategist can work through it before signature and the risk owner can sign knowing each layer is continuous. The checklist turns the abstract worry of the opening scene into a procedure that prevents it.

Build it layer by layer. The security layer: read the SOC 2 Type II report under NDA (scope covers the product, audit period current, exceptions acceptable), confirm ISO 27001 certification and its scope, and verify encryption, access control, logging, subprocessor management, and a breach-notification timeline. The data layer: a contractual data-residency commitment naming the regions and disclosing cross-border subprocessors, an explicit contractual model-training opt-out so your project data does not train the vendor's model, and owner-data handling across its lifecycle (tenant segregation, retention, deletion on request and at termination, with confirmation). The IP layer: the vendor disclaims ownership of submitted model content, limits any license to service provision, settles the rights in AI-generated outputs, and confirms no conflict with the project's AIA E203 and G202 terms. The governance layer: the vendor describes its AI program against the NIST AI RMF functions, Govern, Map, Measure, and Manage, in specifics, and provides the testing and risk documentation the firm needs to extend its own governance.

Produce two things. First, the checklist itself: the four layers, each with its named questions and named evidence, in a form a colleague could run against a real vendor. Second, the prioritization logic: which items are deal-breakers (the absent training opt-out, the SOC 2 scope that does not cover the product, IP terms that conflict with E203 and G202) versus negotiable, and why, so the risk owner knows which gaps stop the signature and which can be papered over with a side agreement. The lasting product is a repeatable procedure the firm runs before every enterprise AI signature, the envelope detail that keeps the owner data and model IP the firm holds but does not own from leaking through a layer nobody checked.

Key Takeaways

• Diligence precedes the signature, not the breach: once the contract is signed and the data flows, the questions you did not ask become risks you cannot retract. This is the cardinal rule (verify before you commit) applied to the vendor relationship, with the contract as the commitment and the diligence as the verification gate.
• Enterprise AI diligence is a layered envelope of four layers, security, data, IP, and governance, each protecting against a distinct failure mode; a gap in any one is a path to the breach even if the others are strong, so the checklist specifies which layer does what and how you confirm each is continuous.
• The security layer rests on SOC 2 Type II (an auditor's confirmation that controls operated effectively over a period, not just designed well at a point in time, as a Type I report attests) and ISO 27001 (a certified, audited information security management system); read the actual report under NDA, confirm its scope covers the product, and read the exceptions, rather than accept the website logo.
• The data layer is the AI-specific layer and the one the opening scene failed: data residency committed contractually by region, a model-training opt-out so your project data does not train the vendor's model, and owner data handling across its lifecycle (segregation, retention, deletion on request and termination, with confirmation), because the firm protects owner data it does not own and holds under a confidentiality duty.
• The IP layer protects model and BIM rights under AIA E203 (the Digital Data Exhibit) and AIA G202 (the BIM Protocol Form, which sets LOD, authorship, and permitted uses): the vendor's terms cannot grant rights exceeding what the firm holds, so the vendor must disclaim ownership of submitted content, limit its license to service provision, settle rights in AI-generated outputs, and confirm no conflict with E203 and G202, because the firm protects model IP it does not own.
• The governance layer asks whether the vendor's AI program is mature using the NIST AI Risk Management Framework and its four functions (Govern, Map, Measure, Manage); because the framework is voluntary rather than certifiable, make the vendor describe its mapping in specifics and obtain the testing and risk documentation the firm needs to extend its own responsible-AI governance over the tool.
• The firm is twice a steward of things it does not own: owner data (the data layer) and model IP whose authorship is distributed among the project parties under E203 and G202 (the IP layer), so a signature cannot give away rights or expose data that belong to others, which is why both layers are deal-breaker territory.
• The deliverable is the diligence checklist, four layers of named questions and named evidence, with a prioritization that separates deal-breakers (absent training opt-out, out-of-scope SOC 2, IP terms conflicting with E203 and G202) from negotiables, so the risk owner signs only when every layer of the envelope is confirmed continuous.