AI 워크플로우가 테이블, 티켓, 운영 문서에서 막히는 이유

1. 마스킹과 삭제가 팀이 가장 먼저 시도하는 이유

기업 AI 파일럿에서 반복되는 패턴이 있습니다. 개념 증명은 깨끗한 텍스트에서 작동하고, 데모는 경영진에게 잘 통하지만, 누군가 실제 서비스 티켓이나 실제 운영 문서에 동일한 워크플로우를 실행하면 결과물이 사용 불가한 상태로 돌아옵니다. 모델은 정상입니다. 통합도 정상입니다. 문제가 생긴 것은 더 구체적인 부분으로 — 거의 항상 입력 데이터가 어떻게 준비되었는지로 추적됩니다.

표준 준비 단계는 어떤 형태든 PII 처리입니다. 마스킹 라이브러리, 가드레일 API, 삭제 처리 과정이 그것입니다. 팀은 이것들 중 하나를 설치하고, 이름과 ID에 맞게 구성하고, 프라이버시 문제가 해결되었다고 가정합니다. 문서의 소수 카테고리 — 민감한 부분이 한 문장 속 이름인 긴 형식 텍스트 — 에서는 이것이 효과가 있습니다. 운영 팀이 실제로 다루는 문서에서는, 진단하는 데 시간이 걸리는 방식으로 실패합니다.

이 직관은 합리적입니다. 문제는 "민감한 데이터가 문서 안에 있고, AI는 그것을 봐서는 안 되므로, 민감한 부분을 제거한다"처럼 보입니다. 그리고 사용 가능한 도구들 — 오픈소스 PII 탐지 라이브러리, 상업용 가드레일 API, 문서 관리 플랫폼에 내장된 삭제 엔진 — 은 모두 그 프레임을 가정합니다. 문서를 가져와 명명 개체를 식별하고, 자리 표시자로 교체하거나 제거합니다.

이 가정은 문서가 비구조화된 긴 산문이고 민감한 콘텐츠가 소수의 명명 개체 언급에 집중되어 있을 때 상당히 잘 성립합니다. 이력서. 계약 요약본. 보도자료 초안. 이러한 것들에서 고객 또는 당사자 이름은 문서의 극히 일부이며, 그것을 제거해도 문서의 의미가 깨지지 않습니다.

문서가 운영 문서인 순간 이 가정은 더 이상 성립하지 않습니다. 그리고 운영 문서가 바로 기업 AI가 실제로 처리하려는 것입니다.

2. 사례 1 — 서비스 티켓

통신 운영 센터의 단일 고객 서비스 티켓을 살펴보겠습니다. 티켓에는 구조가 있습니다. 고객 계정 번호, 장치 시리얼, 영향받은 서비스, 날짜와 시간이 담긴 헤더. 상담원의 자유형 설명: "고객이 Mobile-X 회선의 간헐적 단절을 신고하며, 두 번째 통화 후 1차 지원에서 에스컬레이션됨. 장치가 14:22 UTC에 재설정 이벤트를 표시. 가입자는 물리적 손상은 없다고 확인하지만 지난 화요일 펌웨어 푸시 이후 속도가 느리다고 언급." 네트워크 로그 조각이 담긴 첨부 파일. 지난 달 동일 고객의 다른 티켓 ID 두 건에 대한 참조. 영향받은 회선을 서비스하는 셀 사이트에 대한 자산 참조.

PII 가드레일은 이것을 보고 찾아냅니다. 고객 이름(설명에 이름이 있다면), 아마도 전화번호, 상담원이 고객을 인용했다면 이메일도 가능합니다. 가드레일의 관점에서 그 외의 모든 것은 민감하지 않습니다.

하지만 업종별 데이터 위치 요구사항을 따르는 EU 통신사에게는, 그 외의 거의 모든 것이 어떤 면에서 민감합니다. 셀 사이트 식별자는 지리적 위치 데이터를 드러냅니다. 자산 참조는 펌웨어 푸시 날짜와 결합되면 고객의 하드웨어 구성을 식별할 수 있습니다. 교차 참조된 티켓 ID는 행동 패턴을 드러냅니다. 시리얼 번호는 고유 식별자입니다. 명백한 PII만 제거하면 민감했던 것의 대부분 — 그리고 AI에 유용했던 것의 대부분 — 이 그대로 남은 문서가 됩니다. 고객의 이름은 사라졌지만, 운영자의 CRM에 접근 권한이 있는 누구에게나 고객은 여전히 식별 가능합니다.

그리고 여기에 더 나쁜 절반이 있습니다. 가드레일이 실제로 플래그 지정한 것을 제거하면 AI가 자신의 역할을 수행하는 능력도 깨집니다. 상담원의 자유형 설명은 내내 "고객"을 참조합니다. 헤더에서 고객 이름을 [REDACTED]로 교체하면 자유형 텍스트에는 끊어진 참조가 생깁니다. 돌아오는 AI 요약은 "사용자가 속도 저하를 언급했지만 [REDACTED]도 보고했습니다"와 같은 내용을 말할 것이며, 이는 다음 상담원에게 읽혀도 쓸모가 없습니다.

티켓은 서로 의존하는 식별자, 참조, 맥락적 조각들의 구조입니다. 의존성을 깨뜨리지 않고는 민감한 부분을 끄집어낼 수 없으며, 바로 그 의존성이 AI를 실행할 가치가 있게 만드는 것입니다.

3. 사례 2 — 운영 로그

두 번째 예시: 서비스 중단으로 이어지는 20분간의 알람 이벤트가 담긴 네트워크 운영 센터의 운영 로그 창. 형식은 구조화되어 있습니다. 타임스탬프, 심각도, 장치 ID, 이벤트 코드, 자유형 설명, 상관 ID입니다.

PII 가드레일은 이것을 보고 사실상 아무것도 찾지 못합니다. 고객 이름이 없습니다. 이메일 주소나 전화번호도 없습니다. 필드는 기술 식별자와 이벤트 코드입니다. 가드레일은 로그를 변경하지 않고 반환하며, 팀은 근본 원인 분석을 위해 외부 LLM에 안전하게 전송할 수 있다고 느낍니다.

하지만 대부분의 EU 국가에서 네트워크 운영자에 대한 업종별 약정은 네트워크 토폴로지 자체를 포함합니다. 장치 ID는 인프라 레이아웃을 드러냅니다. 상관 ID와 결합된 알람 시퀀스는 트래픽 라우팅 결정을 드러낼 수 있습니다. 이벤트 코드는 때때로 어떤 장비가 어떤 구간을 운영하는지 공개하는 방식으로 벤더에 특화되어 있습니다. 운영 데이터 처리 위치에 대해 고객 약정을 가진 네트워크 운영자에게, 원시 로그를 제3국 엔드포인트로 전송하는 것이 위반이며, 가드레일은 PII를 발견하지 못했더라도 마찬가지입니다.

구조적 정보 — 무엇이 무엇에 연결되어 있는지, 어떤 순서로 무엇이 실패했는지, 어떤 하위 시스템이 오류를 전파했는지 — 는 AI가 유용한 근본 원인 분석을 수행하는 데 필요한 것입니다. 그것이 또한 로그를 민감하게 만드는 것입니다. 구조를 제거하면 AI는 작업할 것이 없어집니다. 구조를 남겨두면 데이터는 실제로 보호되지 않습니다.

이것이 대부분의 팀이 힘들게 발견하는 부분입니다. 운영 데이터에서 구조가 곧 민감성입니다. 필드 레벨 삭제는 그것을 보지 못하고, 모델링할 수 없으며, 보존할 수 없습니다.

4. 사례 3 — 임상 또는 금융 문서

세 번째 사례는 덜 명백하지만 더 일반적입니다. 임상 워크플로우 문서나 금융 검토 문서입니다. 과거 방문, 검사 결과, 처방, 자유형 임상의 메모에 대한 교차 참조가 있는 환자 레코드. 신청자 데이터, 자산 세부 사항, 거래 이력, 심사역의 서사가 담긴 대출 파일.

이러한 문서들에는 첫 두 사례에 없던 것이 있습니다. PII 가드레일이 포착할 명시적 개인 식별자 — 환자 이름, 생년월일, 계좌 번호, 주민등록번호 — 가 있습니다. 팀은 가드레일을 구성하고 실행하며, 명백한 식별자는 마스킹됩니다. 문서는 깨끗해 보입니다.

하지만 교차 참조는 남아 있습니다. 임상의의 메모는 환자를 "환자"라고 칭합니다 — 괜찮습니다 — 하지만 "이전 입원에서의 결과"와 "세 번째 방문의 약 변경"도 참조합니다. 검사 결과 테이블에는 날짜, 코드, 값이 포함된 구조화된 행이 있습니다. 금융 문서에는 가맹점 이름, 금액, 타임스탬프가 있는 거래 이력이 있습니다.

두 가지가 깨집니다.

1. 교차 참조가 더 이상 해결되지 않습니다. AI는 "이전 입원에서의 결과"를 보지만 이전 입원은 AI에게 그것이 무엇인지 알려주지 않는 토큰으로 마스킹되어 있습니다. AI가 생성하는 요약은 그에 따라 모호합니다.
2. 문서는 명백한 마스킹 후에도 식별 가능한 상태로 남아 있습니다. 환자의 검사 결과 추이는 대략적인 타이밍과 결합되면 이름 없이도 환자를 식별할 수 있습니다. 대출 신청자의 거래 패턴은 대략적인 지역과 자산 참조와 결합되면 신청자를 식별할 수 있습니다. 이러한 재식별 경로는 이론적이지 않습니다. 프라이버시 연구자들이 일상적으로 시연하는 것입니다. 직접 식별자를 포착하지만 구조를 그대로 남겨두는 가드레일은 팀이 생각하는 프라이버시 결과를 실제로 달성하지 못합니다.

결과는 최악의 상황입니다. 교차 참조가 끊겼기 때문에 AI 출력이 저하되고, 재식별을 가능하게 하는 구조적 정보가 여전히 남아 있기 때문에 프라이버시 상태는 실제로 개선되지 않았습니다.

5. 더 나은 가드레일이 이것을 해결하지 못하는 이유

이러한 사례들을 본 후 자연스러운 반응은 더 나은 PII 탐지 엔진을 요청하는 것입니다. 더 넓은 개체 커버리지. 커스텀 규칙 정의. 컨텍스트 인식 탐지. 시장은 이에 응답했습니다 — 이제 수백 가지 개체 유형, 구성 가능한 커스텀 마커, 정규식을 넘어서는 ML 기반 탐지를 갖춘 PII 가드레일이 있습니다.

이것들은 개선이지만 근본 아키텍처를 바꾸지는 않습니다. 아키텍처는 여전히 이렇습니다. 민감 요소를 탐지하고, 제거 또는 교체하고, 결과를 전송합니다. 탐지 레이어가 나아지더라도 삭제 레이어는 여전히 삭제입니다. 그리고 삭제는 항상 같은 것들을 깨뜨립니다. 교차 참조, 구조적 관계, 문서 일관성입니다.

문제를 더 정직하게 프레이밍하면 이렇습니다. AI 워크플로우는 유용한 작업을 수행하기 위해 문서의 구조 — 관계, 참조, 형식, 시퀀스 — 를 필요로 합니다. 프라이버시 제약은 문서의 특정 요소가 외부 모델에 전송될 수 없다고 말합니다. 이 두 가지 사실은 유일하게 가능한 움직임이 제거일 때만 충돌합니다. 식별 콘텐츠를 전송하지 않고 구조를 전송하는 방법이 있다면 충돌은 해소됩니다.

이것이 삭제 기반 접근법(PII 가드레일, 마스킹, 삭제)과 변환 기반 접근법을 구별하는 아키텍처적 전환입니다. 삭제 기반 도구는 꺼내는 것을 최적화합니다. 변환 기반 도구는 사용 가능하게 남는 것을 최적화합니다 — 이는 다른 설계 제약이며, 다른 아키텍처를 만들어냅니다.

6. 마스킹이 실제로 효과가 있는 경우

전통적인 접근법이 괜찮은 경우를 정확히 짚고 넘어갈 필요가 있습니다. 세 가지 조건이 모두 충족되어야 합니다.

• 문서가 구조화된 운영 아티팩트가 아닌 긴 형식의 산문인 경우. 민감한 요소가 콘텐츠의 극히 일부이며 문서는 그것들 없이도 일관되게 읽힙니다.
• AI의 작업이 교차 참조 해결, 구조 보존, 시퀀스 이해를 필요로 하지 않는 경우. 단일 소스 서사 문서를 요약하는 것은 괜찮습니다. 당사자가 유일한 민감 요소라면 계약에서 핵심 조항을 추출하는 것도 괜찮을 수 있습니다.
• 프라이버시 제약이 구조적 정보가 아닌 명명 개체에 관한 것인 경우. 우려가 "고객 이름이 외부 모델에 보여서는 안 된다"는 것이라면 마스킹이 해결합니다. 우려가 "이 문서는 집합적으로 이름 없이도 고객을 식별한다"는 것이라면 마스킹은 해결하지 못합니다.

이러한 경우 — 실제로 존재합니다 — 잘 구성된 PII 가드레일은 합리적인 도구입니다. 실수는 기업의 나머지 문서들이 이것들과 같다고 가정하는 것입니다.

7. 워크플로우 아키텍처에 대한 의미

이러한 사례들에 몇 번 부딪힌 후 대부분의 팀이 내리는 결론은, 데이터 준비 레이어가 삭제와 다른 무언가를 해야 한다는 것입니다. 문서의 구조와 참조를 보존하면서 경계를 넘을 수 없는 요소들을 바꿔야 합니다. 같은 형태, 다른 내용입니다.

그 보존 속성 — 민감한 요소를 컨텍스트 안에서 동일하게 작동하는 자리 표시자로 교체하면서 구조를 유지하는 것 — 이 변환 기반 접근법을 마스킹 및 삭제와 구별합니다. AI는 여전히 서비스 티켓처럼 보이는 문서를 받습니다. 헤더와 자유형 설명과 교차 참조가 있습니다. 외부 모델은 여전히 관계를 추론할 수 있습니다. 출력은 동일한 구조적 역할을 참조하며 돌아옵니다. 기업 환경 내부에서 자리 표시자는 원본 값으로 매핑되어 복원되고, 결과는 실제 이름, 실제 ID, 실제 참조가 담긴 업무 준비 문서가 됩니다.

이것은 마스킹의 다른 구성이 아닙니다. 이는 데이터 준비의 다른 카테고리이며, 기업 문서는 AI에게 있어 콘텐츠만큼이나 구조 안에 가치가 있는 구조화된 아티팩트라는 제약을 중심으로 설계됩니다.