규제 승인을 위한 AI 에이전트 아키텍처 설계 방법은?

규제 당국이 시판 후 조사에서 특히 중요하게 보는 능동적 학습(active learning) 요건을 고려해야 함. 510(k)나 유사한 감사를 통과하려면, 임상의의 모든 수정 사항을 특정 모델 버전 해시와 매핑하는 변경 불가능한 판정 로그가 필요함. 이걸로 사용자 거부 사례를 다음 안전 업데이트에 쓸 수 있는 구조화된 데이터셋으로 바꿀 수 있음.

Class 2를 통과하려면 에이전트가 완전히 감사 가능하지 않은 방식으로 자율적으로 행동하면 안 됨. 효과적인 접근법 하나: 추론과 라이브 UI를 분리하는 것. "실시간" 대화형 에이전트 대신, 데이터가 들어올 때 연구를 처리하는 비동기 추론 서버(예: NVIDIA Triton)를 돌리는 방식임.

규제 범위를 지원한다는 건 에이전트 로직뿐만 아니라 인프라를 안정적으로 유지하는 것도 의미함. 이런 환경에선 데이터 중력(data gravity)이 진짜 병목임. UI가 임상의 속도에 맞춰 고해상도 데이터셋을 빠르게 렌더링하지 못하면 아무리 뛰어난 에이전트도 소용없음. GPU 가속 웹 뷰어(WebGL, Cornerstone)는 이제 선택이 아니라 필수 요구 사항처럼 느껴짐. 파일 렌더링에 30초씩 걸리면 AI로 얻는 효율성은 다 사라짐.

이걸 주로 프롬프트 엔지니어링 문제(출력 안정화를 위한 DSPy 같은 거)로 보는지, 아니면 팀들이 LLM은 개체 추출에만 쓰고 하드코딩된 의사결정 트리로 넘어가는 추세인지 궁금함. 시스템이 에이전트화될수록 62304 규정 준수는 더 어려워지는 것 같음.

Class II는 대부분의 에이전트 실험이 좌초되는 곳임. 감사 추적(audit trail) 요건 하나만으로도 사람들이 열광하는 아키텍처 절반은 죽음. '에이전트가 그렇게 결정했다'가 아니라, 전체 추론 과정을 볼 수 있는 결정론적 출력이 필요함. 규제 환경에서 결정론과 설명 가능성은 있으면 좋은 게 아니라, 그냥 게임의 전부임.