Guardrails First: Engineering Member-Facing Health AI — Rashi Agrawal, Hinge Health

한 줄 핵심

회원의 건강 정보를 다루는 AI는 모델 성능보다 먼저 보안·권한·결정 규칙·지속 평가를 아키텍처로 고정해야만 안전하게 출시할 수 있다.

시간별 요약

1. 0:00
   의료 AI의 현주소와 4,000만 명의 자가 분류 의료 AI는 이미 대규모로 사용되고 있지만, 실제 현장은 안전성 문제가 누적된 생산 환경에 가깝다. 회원이 자신의 건강 문제를 맡기는 서비스라면 모델을 잘 쓰는 것보다 먼저 어떤 위험을 구조적으로 막을지 정해야 한다.
2. 1:04
   챗봇이 만든 중독 사고 일반적인 AI 조언을 그대로 따랐다가 bromine sodium bromide를 섭취해 응급실에 간 사례는, 잘못된 답변이 직접적인 신체 피해로 이어질 수 있음을 보여준다. 건강 조언 영역에서는 작은 환각도 허용되지 않는다.
3. 1:30
   응급 상황을 절반이나 놓치는 분류 소비자용 건강 AI는 치명적 응급 상황을 절반가량 낮게 분류할 수 있었고, 환자안전 단체는 챗봇 오용을 핵심 위험으로 지목했다. 따라서 핵심 과제는 모델의 평균 성능이 아니라 고위험 상황에서의 실패를 어떻게 막을지에 있다.
4. 2:35
   세 가지 양보할 수 없는 기반 안전 문제의 대부분은 모델 자체보다 아키텍처 선택에서 시작되며, 절대 틀리면 안 되는 것은 모델 안이 아니라 그 위의 코드로 처리해야 한다. 또한 안전은 한 번의 출시 심사가 아니라 계속 작동하는 평가 층이어야 한다.
5. 3:41
   PHI가 실제로 존재하는 위치 PHI는 로그에서 지우는 대상이 아니라 파이프라인 경계에서부터 유입되지 않게 막아야 한다. 운영 환경과 비운영 환경을 완전히 분리하고, 역할·지역·규제 요건을 아키텍처에 반영해야 데이터 유출이 원천 차단된다.
6. 5:53
   결정적 규칙은 모델 위에 있어야 한다 응급 이송, 911/988 연결, clinician 개입 여부처럼 되돌릴 수 없는 판단은 확률적 모델에 맡길 수 없다. 먼저 코드가 판단하고, 모델은 그 밖의 긴 대화와 다양한 상호작용만 처리해야 한다.
7. 7:27
   랩조차 프롬프트를 신뢰하지 않는다 root, system, developer, user, guideline 같은 권한 계층은 사용자 입력 한 번으로도 흔들릴 수 있으므로, 프롬프트는 보안 경계가 아니다. 진짜 경계는 프롬프트가 아니라 코드이며, 그래서 고위험 판단은 코드로 고정해야 한다.
8. 7:54
   에스컬레이션·의도 라우팅·신원 확인 자해·자살·급성 응급은 모델이 보기도 전에 911 또는 988로 보내야 하며, 질문 의도에 따라 clinical, tech support, education, exercise recommendation 같은 경로를 결정적으로 나눠야 한다. 또한 회원 데이터에 닿는 모든 흐름은 인증으로 신원을 확인해야 한다.
9. 9:39
   지속 평가로서의 안전 평가는 출시 전 체크리스트가 아니라 실제 대화에 계속 적용되는 상시 층이어야 한다. 자동 판정기, 회원 피드백, 표본 트레이스를 함께 써야 하며, 운영에서 새 실패를 발견하는 순간 그것이 곧 새로운 판정 기준이 된다.
10. 12:47
    다섯 이해관계자, 다섯 위험, 다섯 일의 출시 출시 직전에는 clinical, legal, compliance, product, engineering이 같은 이슈를 보고도 서로 다른 위험을 본다. 이때 중요한 것은 누가 더 강하게 주장하느냐가 아니라, 어떤 기준으로 보류·출시·명시적 승인을 결정하느냐이다.
11. 14:02
    결정을 위한 다섯 가지 규칙 최악의 경우를 기준으로 심각도를 정하고, 심각도와 처리 역량을 분리하며, 애매하면 더 안전한 쪽으로 기운다. 또한 조직이 실제로 허용해 온 수준을 기준으로 위험 허용치를 잡고, 사람을 병목이 아니라 전제조건으로 설계해야 한다.
12. 18:10
    점수를 믿기 전에 채점기를 검증하라 평가 점수가 떨어졌다고 곧바로 에이전트를 고치면 잘못된 신호에 반응할 수 있다. 먼저 judge가 맞는지 확인해야 하며, judge가 과잉 판정한 경우엔 judge를, 실제로 모델이 틀린 경우엔 모델을 고쳐야 한다.
13. 20:24
    한 장으로 정리한 전체 이야기 아키텍처 측면에서는 정책보다 설계, 프롬프트보다 코드, 게이트보다 모니터링이 우선이다. 결정 측면에서는 최악의 경우로 판단하고 더 안전한 실수를 기본값으로 삼으며, 조직의 현실과 사람의 개입을 전제로 운영해야 한다.

실무 인사이트

• 의료·금융·보안처럼 되돌릴 수 없는 영역에서는 모델 개선보다 먼저 코드 기반의 차단·라우팅·인증 경계를 세우는 것이 우선이다.
• 운영 평가는 한 번의 런칭 테스트가 아니라 상시 관측 체계로 설계해야 하며, 자동 지표와 사람 검토를 함께 두어야 한다.
• 판정 점수의 하락을 보면 바로 본체를 수정하기보다, 먼저 평가기 자체의 정확도와 편향을 검증하는 절차를 표준화해야 한다.