Fire/EMS is reviewing a CAD AI that reads AVL locations and radio transcripts. What should the architecture review emphasize first?
Select an answer to reveal the explanation.
Short Explanation
Draw the walls: where CAD, AVL, and radio text stop trusting each other and the AI. Assuming everyone’s already friends, or dumping transcripts into open data, skips the hard part of architecture.
Full Explanation
Fire/EMS CAD AI that reads AVL locations and radio transcripts crosses multiple sensitive operational domains. Architecture review should first diagram and enforce explicit trust boundaries between CAD, AVL, radio-transcript sources, and the AI components so each feed’s authentication, data minimization, and allowed flows are intentional rather than assumed. Clear boundaries let reviewers see where location and radio content enter the model path and where compromise would propagate.
Assuming all CAD-adjacent systems already trust each other with no boundaries fails because implicit mesh trust maximizes blast radius when any component is compromised. Documenting only marketing logo placement for the AI vendor fails by substituting branding for security architecture. Merging radio-transcript storage into a public open-data bucket for transparency fails because radio content from emergency response is not open civic data and would expose sensitive operational communications.
Exam caveat: For multi-source emergency AI, start with trust-boundary diagrams and enforcement—not assumed trust or open-data dumping of radio transcripts.
Operational check: Produce a data-flow diagram with labeled trust zones for CAD, AVL, transcripts, and AI; enforce authenticated one-way or mediated feeds; keep transcripts out of public buckets; and verify AI components cannot write unconstrained back into CAD control paths.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.