Courts IT documents system components for the AI inventory. How should foundation-model APIs, fine-tuned local classifiers, and classical models be treated?
Select an answer to reveal the explanation.
Short Explanation
Calling everything “the chatbot” is like labeling every courthouse tool “a hammer.” Foundation APIs, fine-tuned local classifiers, and classical models behave differently and fail differently. Split them on the inventory so oversight can actually work.
Full Explanation
Courts IT documenting system components for the AI inventory should treat foundation-model APIs, fine-tuned local classifiers, and classical models as distinct inventory components because each has different dependencies and oversight needs. Collapsing them hides vendor concentration, data-flow, and validation differences that matter in justice settings.
Why the other options fail by concept: A single undifferentiated chatbot entry with no component breakdown blocks meaningful audit. Treating distinctions as optional trivia that audits never need is incompatible with risk management. Calling the labels interchangeable so they do not affect risk or vendor controls ignores that API terms, weight ownership, and classical feature pipelines imply different failure and contract regimes.
Exam caveat: One user-facing “assistant” may compose multiple components; inventory the components, not only the product nickname. Classical models remain AI for governance purposes when they score or classify in production.
Operational check: Split the courts inventory into API foundation usage (provider, data sent, logging), fine-tuned local classifiers (training set, eval, hosting), and classical models (features, owners). Map controls per component and verify sealed or sensitive data never enters unauthorized foundation-API paths.