A county IT board asks audit to confirm an AI solution’s alignment before funding. What fit should audit evaluate?
Select an answer to reveal the explanation.
Short Explanation
You shouldn’t judge county AI fit by cost estimates against approved contracting and licensing models. Audit checks that it plugs into the enterprise architecture—identity, logging, integrations—the same way other systems must.
Full Explanation
Before funding, a county IT board should have audit evaluate alignment with enterprise architecture standards and approved integration patterns. Conformance to application coding guidelines and interface design conventions is a development-detail concern, not the enterprise-architecture fit that determines whether county AI avoids shadow-system risks. Fit means SSO/IAM patterns, approved APIs, logging and monitoring sinks, data classification handling, encryption in transit/at rest, and network zones—not merely alignment of model performance targets with operational service metrics.
Evaluation of project cost estimates against approved contracting and licensing models is a procurement control, not an architecture-alignment gate, and it does not establish whether the AI solution uses county-approved integration patterns. Alignment of model performance targets with operational service metrics measures model quality, not architectural fit, and ignores production operability, supportability, and handover. Conformance to application coding guidelines and interface design conventions is a development concern, not the enterprise-architecture alignment that prevents integration debt and assurance gaps when the pilot becomes a service.
Exam caveat: enterprise architecture alignment is a governance gate for AI the same as for conventional systems; novelty does not create an exemption. Operational check: require EA sign-off artifacts, a pattern-compliance checklist covering authN/Z, encryption, and logging, and reject funding packages lacking named integration owners and runbooks.