AI agent evaluation in New York.

The technical reality of AI evaluation in New York institutions.

Questions from New York buyers.

Our bank's model risk team speaks SR 11-7. What evaluation evidence do they expect for an LLM system?

The same conceptual artifacts they expect for any model, translated to generative behavior. Concretely: documented intended use and limitations (what the system is for, what it must not be used for), an evaluation design tied to that use (test sets representative of production inputs, metrics that map to the harms that matter: faithfulness to sources, error rates by class, refusal correctness), results with thresholds and sign-offs, ongoing monitoring with drift triggers, and change management (what re-runs when prompts, models, or retrieval corpora change). What is different for LLM systems is the test construction: behavioral suites instead of backtests, adversarial and edge-case sets alongside the representative ones, and trajectory-level checks for agents that take multi-step actions. We build the package in your model-risk team's vocabulary, and validation teams generally engage well once the artifacts look like artifacts they know how to challenge.

We use AI in hiring-adjacent workflows. How does NYC Local Law 144 touch our evaluation obligations?

If your tool substantially assists or replaces discretionary hiring or promotion decisions for NYC candidates, Local Law 144 requires an independent bias audit (selection-rate analysis by race/ethnicity and sex) published before use, plus candidate notice. The evaluation work splits cleanly: the statutory bias audit itself must be performed by an independent auditor, which we are not for this purpose and will say so plainly; what we build is everything that makes such audits and your own diligence tractable: instrumentation that logs the decision-relevant outputs auditors need, internal disparate-impact dashboards run continuously rather than annually, test suites that catch regression in screening behavior before deployment, and documentation of what the system actually influences (which often narrows the legal exposure honestly). Several adjacent tools fall outside the law's scope; mapping yours against it is counsel's call, and our instrumentation gives counsel real data to rule on.

Legal and research outputs must be faithful to sources. How is faithfulness actually measured?

By decomposing outputs into claims and verifying each against the cited source, at scale. The harness: every generated summary or answer is split into atomic claims; each claim is checked against the retrieved passages it cites (an LLM judge does the volume, calibrated against attorney- or analyst-graded samples until agreement is demonstrated); and the metrics that come out are precise enough to act on: claim-support rate, citation accuracy (does the cite point where the claim lives), and fabrication rate by document type. Thresholds then gate releases: a research assistant might ship at 98 percent claim support with flagged uncertainty on the rest, while a client-facing drafting tool holds a higher bar with mandatory human review. The eval set is built from your documents (filings, agreements, briefs), because faithfulness on Wikipedia proves nothing about behavior on a credit agreement's defined terms.

Our agent takes multi-step actions, not just answers. What does trajectory evaluation add?

It tests the path, not just the destination, which is where agent failures actually live. Output-only evaluation misses the agent that got the right answer by calling the wrong tool with someone else's data, retried a payment action three times, or wandered through seven steps where two sufficed. Trajectory evaluation scores the sequence: tool-call correctness (right tool, right arguments, right order), permission boundaries respected at every step, efficiency (steps and tokens against a reference path), recovery behavior when a tool fails, and stopping discipline (no action loops, clean handoffs when stuck). The harness replays recorded scenarios and synthetic edge cases against the agent in a sandboxed environment with mocked tools, so a misbehaving trajectory costs nothing real. For New York systems touching money movement or client data, trajectory gates are the difference between an agent you demo and one you let touch production credentials.