SOX vendor evaluation criteria for enterprise AI implementation — Reference Architecture

Reference architecture · published 2026-10-16 · regulated enterprise · SOX · layout control_review · implementation executed in CI before publish

The control that resolves this is a Gated Vendor Evaluation Framework, evaluated before the request reaches a model provider rather than audited afterwards. In regulated enterprise the binding constraint is SOX, and the question it actually asks is can an AI-influenced number in a filing be traced and reproduced. The specific problem here is RFP and structured evaluation. The shape below holds p95 ≤ 600ms over gRPC with mTLS, and ships with a standard-library implementation that runs as written.

The architecture friction point

A vendor comparison built as a weighted average lets a supplier average its way past a control it does not have. The scorecard ranks everyone, the committee cannot see which gates were failed, and the decision gets re-litigated after the contract is signed.

What makes RFP and structured evaluation specifically hard

An RFP scored as a weighted average lets a vendor average its way past a control it does not have. The scoring model, not the questions, is usually what makes the evaluation indefensible.

What resolves it is a two-layer scorecard: pass/fail gates, then weights. The failure to design against: the highest-scoring vendor failing security review after award.

What SOX specifically requires

SOX cares about the integrity of financial reporting. If a model output touches a number that reaches a filing, the control question is whether that output can be reproduced exactly and attributed to a reviewed, approved version.

The artifact that satisfies it is reproducible output records pinned to a model version. The way teams most often fail it: a model upgrade changing a reported figure with no record of which version produced the original.

Controls and acceptance parameters

Each row carries an acceptance parameter rather than an adjective, because "low latency" cannot be signed off. Retention here is bound by per the data class retention schedule, enforced automatically.

Deployment parameters

Every value below is a parameter you can hold a vendor or an internal team to. Adjectives are not acceptance criteria.

Review questions and answers

• Reproduce last quarter's figure exactly, using the model version that produced it.
  Version, prompt digest and output digest are recorded per reporting-relevant inference, and versions are pinned per period, so the figure is reproducible on demand.
• Which criteria are pass/fail, and which vendor failed one?
  Gates are evaluated first and independently of score: SOC 2 Type 2 currency, DPA and subprocessor disclosure, tenant isolation evidence, residency. A failure on any of them disqualifies.
• Which criteria are pass/fail, and which vendor failed one?
  The gate layer is pass/fail: SOC 2 Type 2 currency, DPA and subprocessor disclosure, tenant isolation evidence, and data residency. Gates are evaluated before any weighted scoring, so a vendor cannot average past a control it lacks.
• For each passed gate, what artifact proves it and what is its date?
  Each gate names the artifact that satisfies it — the report, the signed DPA, the architecture document — with its date. A claim is not evidence.
• Is the latency target in the signed agreement with a remedy, or on a status page?
  It must be in the signed agreement with a remedy. A status page is not a commitment; the scorecard scores the remedy, not the promise.
• What does exit look like — specifically, what can you export and has it been rehearsed?
  Export of prompts, embeddings, eval sets and fine-tunes, rehearsed during the pilot rather than promised in the contract. Portability that has never been executed is not portability.
• Was the reference deployment in the same vertical and regulatory regime as ours?
  It must be — a reference in the same vertical and the same regulatory regime, worked through a structured question set, not a vendor-selected happy customer.

Reference architecture

Gated Vendor Evaluation Framework — the request path, with the decision points that must exist before the first model call:

flowchart TB
    V[Vendor responses] --> G{Gates - pass/fail}
    G -->|any gate failed| DQ[Disqualified<br/>with named gates]
    G -->|all gates passed| W[Weighted scoring]
    W --> TCO[3-year fully loaded TCO]
    W --> REF[Reference call<br/>comparable regulated deployment]
    TCO --> R[Ranking]
    REF --> R
    R --> DR[Decision record<br/>score + reason per criterion]
    DQ --> DR
    DR --> SC[Steering committee]

Implementation components

1. Gate layer — Pass/fail controls: SOC 2 Type 2 currency, DPA, tenant isolation, residency.
2. Weighted layer — Ranks only vendors that cleared every gate.
3. Evidence requirement — Each gate names the artifact that satisfies it, not a claim.
4. TCO model — Fully loaded three-year: licence, run cost, internal effort.
5. Reference protocol — A structured call with a comparable regulated deployment.
6. Decision record — Ranking plus failed gates plus a written reason per score.

Reference implementation — Weighted scorecard with disqualifying gates

Standard-library Python, no external dependencies, runs as written. Executed by the publish gate: if it raises, this page does not ship. Wire it behind gRPC with mTLS; the failure mode it guards against is a half-open HTTP/2 stream silently dropping the deadline. The output you hand the assessor is the reporting-period reproducibility record.

"""Weighted vendor scorecard with disqualifying gates.

Why this shape: a procurement scorecard that is a weighted average lets a vendor
average its way past a control it simply does not have. Real evaluations have
two layers — GATES that are pass/fail, and weights that only ever rank the
vendors that already cleared every gate.

This produces the artifact a steering committee signs: a ranking, the gates each
vendor failed, and a written reason per score.
"""
from dataclasses import dataclass, field


@dataclass(frozen=True)
class Criterion:
    key: str
    weight: float          # relative; normalised at scoring time
    gate: bool = False     # True -> pass/fail, cannot be averaged away
    note: str = ""


DEFAULT_CRITERIA = [
    Criterion("soc2_type2_current", 0.0, gate=True,
              note="Type 2 report inside 12 months, not a Type 1 or a roadmap"),
    Criterion("dpa_and_subprocessors", 0.0, gate=True,
              note="DPA signable as-is and a disclosed subprocessor list"),
    Criterion("tenant_isolation_evidence", 0.0, gate=True,
              note="Architectural isolation, not a WHERE clause"),
    Criterion("data_residency", 0.0, gate=True,
              note="Processing stays in the contracted region"),
    Criterion("exit_and_portability", 2.0,
              note="Export of prompts, embeddings, evals; no model lock-in"),
    Criterion("latency_slo_contractual", 3.0,
              note="p95 in the agreement with a remedy, not a status page"),
    Criterion("integration_depth", 3.0,
              note="Works against the real system of record, not a demo schema"),
    Criterion("implementation_capacity", 2.0,
              note="Named engineers, not a bench claim"),
    Criterion("tco_3yr", 3.0, note="Fully loaded: licence, run, internal effort"),
    Criterion("reference_in_our_vertical", 2.0,
              note="A reference call with a comparable regulated deployment"),
]


class Disqualified(Exception):
    pass


@dataclass
class Vendor:
    name: str
    gates: dict = field(default_factory=dict)    # key -> bool
    scores: dict = field(default_factory=dict)   # key -> 0..5
    reasons: dict = field(default_factory=dict)


def evaluate(vendors, criteria=None):
    """-> (ranked, disqualified). Gates are evaluated first, always."""
    criteria = criteria or DEFAULT_CRITERIA
    gate_keys = [c.key for c in criteria if c.gate]
    weighted = [c for c in criteria if not c.gate and c.weight > 0]
    total_w = sum(c.weight for c in weighted) or 1.0

    ranked, disqualified = [], []
    for v in vendors:
        failed = [k for k in gate_keys if not v.gates.get(k, False)]
        if failed:
            disqualified.append({"vendor": v.name, "failed_gates": failed})
            continue
        got = 0.0
        breakdown = []
        for c in weighted:
            s = float(v.scores.get(c.key, 0))
            if not 0 <= s <= 5:
                raise ValueError(f"{v.name}.{c.key}={s} outside 0..5")
            contribution = (c.weight / total_w) * (s / 5.0)
            got += contribution
            breakdown.append({"criterion": c.key, "score": s,
                              "weight": c.weight,
                              "contribution": round(contribution, 4),
                              "reason": v.reasons.get(c.key, ""),
                              "standard": c.note})
        ranked.append({"vendor": v.name, "score": round(got * 100, 1),
                       "breakdown": breakdown})
    ranked.sort(key=lambda r: -r["score"])
    return ranked, disqualified


if __name__ == "__main__":
    passing = {k: True for k in
               ("soc2_type2_current", "dpa_and_subprocessors",
                "tenant_isolation_evidence", "data_residency")}
    a = Vendor("Vendor A", gates=dict(passing),
               scores={"exit_and_portability": 4, "latency_slo_contractual": 5,
                       "integration_depth": 4, "implementation_capacity": 3,
                       "tco_3yr": 3, "reference_in_our_vertical": 5},
               reasons={"latency_slo_contractual": "p95 450ms with 10% credit"})
    b = Vendor("Vendor B", gates={**passing, "tenant_isolation_evidence": False},
               scores={k: 5 for k in
                       ("exit_and_portability", "latency_slo_contractual",
                        "integration_depth", "implementation_capacity",
                        "tco_3yr", "reference_in_our_vertical")})
    ranked, dq = evaluate([a, b])
    for r in ranked:
        print(f"{r['vendor']}: {r['score']}")
    print("disqualified despite perfect scores:", dq)

The SOX control, as code

Segregation of duties over model releases. This is the artifact an assessor asks for under SOX specifically — it is not the same control as the one above, and a system that implements one does not thereby implement the other. It executes under the same publish gate.

"""Segregation of duties over model releases, with an immutable approval chain.

SOX cares about change management over systems affecting financial reporting.
The control that fails is the one where the person who wrote the change also
approved and deployed it, and where the approval record can be edited after the
fact. Both are structural, so both are enforced here rather than reviewed.
"""
import hashlib
import json


class ApprovalChain:
    """Append-only. Each link commits to the previous digest, so an edited
    record breaks verification rather than quietly rewriting history."""

    def __init__(self):
        self.links: list[dict] = []

    def _head(self) -> str:
        return self.links[-1]["digest"] if self.links else "genesis"

    def append(self, action: str, actor: str, change_id: str) -> dict:
        body = {"action": action, "actor": actor, "change_id": change_id,
                "prev": self._head()}
        digest = hashlib.sha256(
            json.dumps(body, sort_keys=True).encode()).hexdigest()
        link = dict(body, digest=digest)
        self.links.append(link)
        return link

    def verify(self) -> bool:
        prev = "genesis"
        for link in self.links:
            body = {k: link[k] for k in ("action", "actor", "change_id", "prev")}
            if link["prev"] != prev:
                return False
            if hashlib.sha256(
                    json.dumps(body, sort_keys=True).encode()).hexdigest() != link["digest"]:
                return False
            prev = link["digest"]
        return True

    def actors(self, change_id: str, action: str) -> set[str]:
        return {l["actor"] for l in self.links
                if l["change_id"] == change_id and l["action"] == action}


class ReleaseGate:
    def __init__(self, chain: ApprovalChain):
        self.chain = chain

    def author(self, change_id: str, actor: str) -> None:
        self.chain.append("author", actor, change_id)

    def approve(self, change_id: str, actor: str) -> None:
        if actor in self.chain.actors(change_id, "author"):
            raise PermissionError(
                f"{actor} authored {change_id}; approval requires a second person")
        self.chain.append("approve", actor, change_id)

    def deploy(self, change_id: str, actor: str) -> dict:
        if not self.chain.actors(change_id, "approve"):
            raise PermissionError(f"{change_id} has no approval")
        if actor in self.chain.actors(change_id, "author"):
            raise PermissionError(f"{actor} authored {change_id}; cannot deploy it")
        return self.chain.append("deploy", actor, change_id)


if __name__ == "__main__":
    chain = ApprovalChain()
    gate = ReleaseGate(chain)

    gate.author("MODEL-2026-114", "r.khare")
    try:
        gate.approve("MODEL-2026-114", "r.khare")
        raise AssertionError("self-approval was permitted")
    except PermissionError:
        pass

    gate.approve("MODEL-2026-114", "a.controller")
    try:
        gate.deploy("MODEL-2026-114", "r.khare")
        raise AssertionError("author deployed their own change")
    except PermissionError:
        pass

    link = gate.deploy("MODEL-2026-114", "o.release")
    assert chain.verify(), "chain must verify after a legitimate sequence"
    assert link["action"] == "deploy"

    try:
        gate.deploy("MODEL-2026-999", "o.release")
        raise AssertionError("deployed an unapproved change")
    except PermissionError:
        pass

    # Tampering must be detectable, not merely discouraged.
    chain.links[1]["actor"] = "r.khare"
    assert not chain.verify(), "edited approval record still verified"

    print("SOX segregation of duties + approval chain: OK")
    print(f"  links {len(chain.links)}, verifies_after_tamper={chain.verify()}")

See also

• Part of enterprise ai vendor evaluation.
• The same control appears in GDPR vendor evaluation criteria for enterprise AI implementation.
• For the related constraint, see PCI DSS 4.0 vendor evaluation criteria for enterprise AI implementation.
• This pattern also governs fedRAMP Moderate vendor evaluation criteria for enterprise AI.
• Where this interacts with another regime, see SOC 2 Type II vendor evaluation criteria for enterprise AI implementation.
• If this is the blocker in front of you: enterprise AI infrastructure review.