A transit authority wants generative AI that drafts rider alerts. What should audit confirm before model selection proceeds?

Before a transit authority selects a generative model to draft rider alerts, audit should confirm that documented business and service requirements are traced to enterprise rider-communication objectives. Model selection without a requirements baseline turns procurement into a demo contest. Rider alerts implicate safety messaging, accessibility, multilingual reach, channel latency, approval workflows, and brand/voice standards; those needs must be written and linked to agency communication goals so architecture, evaluation data, and vendor claims can be tested against something objective.

Relying on production monitoring dashboards for live alert drift and helpfulness puts operational oversight before the selection decision; audit must first confirm requirements are traced to communication objectives, not verify dashboards that only exist after a model is chosen. Promoting fine-tuned weights for historical rider voice and tone to staging is a model-selection artifact, not an audit precondition; it does not establish that business and service requirements are tied to enterprise rider-communication objectives. Finalizing vendor service-level commitments for uptime with procurement is a contracting step that follows model selection; it does not substitute for the audit confirmation that documented requirements are traced to rider-communication objectives before any model is chosen.

Exam caveat: “requirements exist somewhere in a Slack thread” is not the same as controlled, versioned requirements used in selection and acceptance. Operational check: verify a signed requirements artifact maps alert use cases to service objectives, defines prohibited content (e.g., unverified delay causes), and feeds measurable acceptance tests before shortlisting models.