데모는 잘 진행되었습니다. 모델은 정확하게 답변했고, 이해관계자들은 고개를 끄덕였으며, 누군가는 "이것을 프로덕션(Production)에 적용합시다"라고 말했습니다. 그게 6개월 전의 일입니다. PoC(Proof of Concept, 개념 증명)는 여전히 실행 중이고, 로드맵에는 여전히 기재되어 있지만, 데모 당일보다 제품 출시(Shipping)에 더 가까워진 것은 전혀 없습니다.

만약 당신이 은행, 보험사, 또는 규제 대상 기업에서 AI 시스템을 구축하고 있다면, 아마도 이런 상황이 발생하는 것을 목격했을 것입니다. 불편한 사실은 이렇습니다. PoC는 버그 때문에 막힌 것이 아니었습니다. 아무도 긋지 않은 선에 의해 막힌 것이었습니다.

PoC는 아직 존재하지도 않는 선의 잘못된 쪽에 구축되었습니다

전형적인 개념 증명(PoC)은 호스팅된 프런티어 모델(Frontier Model) API를 호출합니다. 이는 PoC를 위한 올바른 선택입니다. 최고의 성능, 인프라 구축 불필요, 단 하루 만의 통합이 가능하기 때문입니다. 합성 데이터(Synthetic Data)나 비식별 처리된(Scrubbed) 데이터를 사용할 때는 아무도 반대하지 않습니다.

하지만 프로덕션 데이터는 차원이 다른 문제입니다. 첫 번째 검토 회의에서는 아키텍처(Architecture)가 답할 수 없는 질문들이 쏟아집니다:

• 이 워크로드(Workload)가 어떤 데이터 클래스를 외부로 전송하며, 그 목록을 누가 승인했는가?
• 추론(Inference)은 어디에서 일어나는가? 데이터베이스가 프랑크푸르트에 머물러 있더라도, 해외에 호스팅된 모델로 라우팅된 쿼리는 이미 관할권을 벗어난 것이다.
• 감사 증거(Audit Evidence)는 어디에 있으며, 벤더(Vendor)의 로그 보존 정책이 감독 기관의 요구를 충족할 수 있는가?
• 감사인이 질문할 때 이 시스템의 책임자는 누구인가? EU AI Act 제26조에 따라, 벤더 계약 내용과 관계없이 운영자(Operator)의 의무는 귀사에 귀속된다.

이 중 그 어떤 것도 모델 품질에 관한 질문이 아닙니다. 모델은 괜찮습니다. 문제는 아키텍처에 이러한 답변을 담을 공간이 없다는 것입니다.

사후 수정(Retrofit)의 함정

본능적으로 우리는 패치(Patch)를 시도합니다. 비식별화 레이어(Redaction Layer)를 추가하고, 로그를 옮기고, 벤더 계약을 수정하고, 정책 문서를 작성합니다. 각 패치는 다음 검토를 유발합니다. 계약서는 다시 작성됩니다. 데이터 흐름은 재설계됩니다. 승인 절차는 다시 열립니다. 모든 새로운 유스케이스(Use Case)는 처음부터 자신의 경계를 다시 협상해야 하며, 당신의 백로그(Backlog)는 단 하나의 컴플라이언스(Compliance, 준수) 팀 뒤에 줄을 서게 됩니다.

이 루프 속에서 어떤 프로젝트도 거절되지 않습니다. 단지 통과되지 못할 뿐입니다. 이것이 6개월이 지난 후에도 PoC가 여전히 "검토 중"인 이유입니다.

제품을 출시하는 팀은 무엇이 다른가

제가 본 규제 대상 팀 중 프로덕션에 도달한 팀들은 모두 동일한 조치를 취했습니다. 바로 아키텍처 (Architecture)를 확정하기 전에 컴플라이언스 경계 (Compliance boundary)를 설정한 것입니다.

Sovereign baseline inside the boundary: regulated data, model weights, inference, audit logs under the company's own keys. Frontier APIs outside for public and cleared data. One routing rule between them.

이 패턴은 세 가지 부분으로 구성됩니다:

1. 유스케이스 (Use cases)가 아닌 데이터를 분류하십시오. 외부 서비스로 넘어갈 수 있는 데이터 클래스 (Data classes)의 짧은 목록과, 절대 넘어가지 않을 목록을 만드세요. 고객의 개인정보 (PII) 및 스코어링 기능은 내부에 유지하고, 공개 및 승인된 데이터는 외부로 나갈 수 있습니다.
2. 단일 게이트웨이 (Gateway), 단일 라우팅 규칙 (Routing rule). 모든 모델 호출은 데이터 클래스에 따라 경로를 지정하는 단일 지점을 통과합니다. 규제 대상 데이터는 귀하가 제어하는 인프라 내에서 귀하의 관할권(Jurisdiction) 안에서 실행되는 모델로 전송됩니다. 오픈 웨이트 (Open-weight) 모델은 대부분의 좁은 범위의 워크로드 (분류, 추출, 요약)를 잘 처리합니다. 승인된 모든 데이터는 프런티어 API (Frontier API)로 전송되어 유로당 최고의 성능을 얻습니다.
3. 경계 내부의 증거. 감사 로그 (Audit logs), 라우팅 결정, 데이터 흐름도 (Data-flow diagram)는 지정된 한 명의 소유자가 서명한 상태로 경계선의 귀하 측에 존재합니다.

경계가 설정되면, "이것을 출시할 수 있을까요?"라는 질문은 6개월간의 협상이 아닌 라우팅 문제로 바뀝니다. 감사인은 풀어헤쳐야 할 40개의 통합(Integration) 대신 테스트할 단 하나의 라인을 갖게 됩니다.

현재 가지고 있는 PoC를 어떻게 해야 하는가

PoC를 버릴 필요는 없습니다. 세 단계가 있습니다:

1. PoC가 실제로 수행하는 워크로드에 대한 데이터 클래스 목록을 작성하고, 컴플라이언스 팀의 승인을 받으세요. 이는 단 한 페이지에 불과하므로 몇 달이 아닌 며칠이면 충분합니다.
2. 모델 호출 앞에 아주 얇은 형태라도 게이트웨이를 배치하세요. 첫날부터 데이터 클래스에 따라 라우팅하십시오.
3. 규제 대상 부분만 경계 내부로 이동시키세요. 승인된 모든 것에 대해서는 프런티어 API를 유지하십시오. 분류 체계가 존재하면 대부분의 PoC는 깔끔하게 분리됩니다.

프로덕션에 도달하는 PoC는 드물게 가장 인상적인 PoC인 경우가 많습니다. 그것은 데이터 흐름이 첫 번째 검토 회의를 통과하는 PoC입니다.

저는 규제 산업 (regulated industries)의 팀들이 AI 프로토타입을 관리된 프로덕션 워크플로 (governed production workflows)로 전환할 수 있도록 돕고 있습니다. 제가 아키텍처 검토 (architecture review)를 진행하기 전에 실행하는 컴플라이언스 준비 상태 체크리스트 (compliance readiness checklist)는 renezander.com/gdpr-checklist에서 확인하실 수 있습니다.