CSV에서 CSA로의 전환 플레이북: 품질팀이 실제로 실행해야 하는 과제

중견 제약회사의 한 밸리데이션 엔지니어가 교육 관리 모듈에 대한 47개의 스크립트 기반 테스트 케이스(scripted test cases)를 작성하느라 3주를 보냅니다. 모든 단계마다 스크린샷이 첨부되고, 모든 기대 결과(expected results)가 꼼꼼히 문서화됩니다. 완성된 밸리데이션 패키지는 180페이지에 달합니다. 내부 감사자(internal auditor)는 이를 검토하여 결함이 없음을 확인하고 최종 승인(sign-off)합니다.

그러나 6개월 후, 해당 모듈은 실제 운영 환경(production)에서 중대한 워크플로우 오류를 일으킵니다. 실패의 원인은 47개의 스크립트 중 단 하나도 다루지 않았던 경계 조건(boundary condition)에 있었습니다. 스크립트들이 시스템의 ’취약점과 결함이 어디에 있는지’를 찾아내기 위함이 아니라, 시스템이 ’정상 작동함’만을 입증하기 위해 작성되었기 때문입니다.

이것이 바로 전형적인 ’CSV(Computer System Validation, 컴퓨터 시스템 밸리데이션)의 함정’입니다. 그리고 이것이 바로 미국 식품의약국(FDA)의 컴퓨터 소프트웨어 보증(CSA, Computer Software Assurance) 프레임워크가 해결하고자 설계된 핵심 문제입니다.

핵심 역설 (The Core Paradox)

CSV에서 CSA로의 전환에서 마주하는 가장 본질적인 갈등은 다음과 같습니다: 조직은 문서화 작업량을 획기적으로 줄이는 동시에, 훨씬 더 높은 수준의 보증(assurance)을 달성해야 합니다. 이는 CSA가 실제로 무엇을 변화시키는지 이해하기 전까지는 모순처럼 들릴 수 있습니다.

전통적인 CSV는 묻습니다: “요구된 모든 테스트 스크립트를 빠짐없이 실행했는가?”

반면 CSA는 묻습니다: “이 소프트웨어가 의도된 용도(intended use)에 맞게 안전하게 작동한다는 확신을 가지고 있는가?”

첫 번째 질문은 산출물의 ’양(volume)’을 보상합니다. 두 번째 질문은 전문적인 ’판단(judgment)’을 보상합니다. 이 두 가지 질문은 근본적으로 서로 다른 밸리데이션 패키지, 서로 다른 테스트 전략, 그리고 완전히 다른 품질 조직을 만들어냅니다.

FDA는 2025년 9월 최종 CSA 가이드라인을 확정 발표했으며, ISO 13485:2016을 21 CFR Part 820에 통합한 새로운 품질경영시스템 규정(QMSR)과 정렬하기 위해 2026년 2월 이를 추가 개정했습니다. 이는 초안(draft)이 아닙니다. 현재 규제 당국이 현장에 요구하는 공식 규제 기대사항(regulatory expectation)입니다. 또한 생산 및 품질 시스템 소프트웨어에 적용되던 기존 ‘소프트웨어 밸리데이션의 일반 원칙(General Principles of Software Validation)’ 가이드라인의 섹션 6을 공식적으로 대체합니다.

CSA가 변경하지 않는 사항

어떤 변화가 필요한지 구체적으로 다루기 전에, 무엇이 변경되지 않는지를 명확히 짚고 넘어갈 필요가 있습니다:

고위험 기능은 여전히 엄격한 스크립트 기반 테스트를 유지합니다. 제조실행시스템(MES) 레시피 실행, 실험실정보관리시스템(LIMS) 검체 적합/부적합(pass/fail) 판정, 전자배치기록(EBR) 계산 등 환자 안전, 제품 품질, 또는 배치 출하(batch release)에 직접적인 영향을 미치는 기능은 여전히 추적성(traceability)과 공식적인 결함 관리(defect handling)를 수반하는 완전한 스크립트 기반 검증을 거쳐야 합니다.
21 CFR Part 11 요구사항은 전혀 변하지 않았습니다. 전자서명, 감사 추적(Audit Trail), 접근 제어(Access Control)는 여전히 타협할 수 없는 필수 요건입니다.
기존에 밸리데이션된 시스템은 유효 상태를 그대로 유지합니다. 기존에 완료된 CSV 패키지를 소급하여 CSA 체계로 강제 변환할 필요는 없습니다. CSA는 신규 시스템 도입 및 중대한 변경(material changes) 시점부터 전향적으로(forward) 적용합니다.
객관적 증거(Objective Evidence)는 여전히 필수입니다. 증거의 ’형태(form)’가 변화할 뿐, 증거 확보에 대한 규제적 요구사항 자체는 조금도 변하지 않았습니다.

1단계: 기반 재구축 (1~4주차)

CSA 입장 문서(Position Paper) 발행

첫 번째 산출물은 QA 리더십이 서명한 2페이지 분량의 공식 메모(Position Paper)입니다. 여기에는 다음 세 가지 사항이 명시되어야 합니다:

당 조직은 21 CFR 820.70(i), 820.75 및 QMSR에 대한 공식적 해석이자 운영 지침으로서 FDA의 컴퓨터 소프트웨어 보증(CSA) 가이드라인을 채택한다.
과거 CSV의 의미(소모적이고 획일적인 일률적 테스트)와 CSA가 의미하는 바(위험에 비례한 검증 노력 투입)를 명확히 정의한다.
기존에 밸리데이션된 시스템의 적격 상태는 그대로 유지된다.

이 문서는 단순한 요식 행위가 아닙니다. 밸리데이션 엔지니어들이 “우리는 지금까지 그런 식으로 일하지 않았다”라는 조직적 저항에 직면할 두려움 없이 행동 양식을 바꿀 수 있도록 정당성을 부여하는 일종의 ‘공식 허가증’ 역할을 합니다.

의도된 용도별 인벤토리 재정비

기존 CSV 인벤토리는 단순히 시스템 이름만을 나열했습니다. 반면 CSA 인벤토리는 의도된 용도(intended use)에 따른 기능을 목록화합니다.

모든 컴퓨터화 시스템에 대해 다음 질문을 던져야 합니다: “이 기능이 생산 또는 품질 시스템의 일부로 직접 사용되는가?”

범주	예시	CSA 접근 방식
직접 영향 (Direct impact)	MES 레시피 실행, LIMS 검체 적합/부적합 판정, eQMS 승인 워크플로우	완전한 보증(Full assurance), 고위험 기능에 대한 스크립트 기반 테스트
생산 지원 (Supports production)	ERP 재고 추적, 이슈 관리/트래킹, 장비 교정(Calibration) 도구	엄격도 완화, 중위험 기능에 대한 비스크립트(Unscripted) 테스트 적용
대상 제외 (Out of scope)	이메일, 일반 BI 대시보드, 일반 사무용 오피스 도구	공급업체 평가(Vendor assessment)만 수행하거나 타당한 근거 기반 면제

여기서 핵심적인 패러다임 전환이 발생합니다: 단 하나의 단일 시스템이라도 위의 세 가지 범주 모두에 걸쳐 있을 수 있다는 점입니다. 예를 들어 eQMS(전자 품질경영시스템)에는 고위험 기능(전자서명, 승인 워크플로우, 감사 추적)과 저위험 기능(검색, 대시보드, UI 환경 설정)이 공존합니다. CSA는 시스템 단위가 아니라 ’기능(function) 단위’로 위험을 평가합니다.

다기능 태스크포스(Cross-Functional TF) 구성

CSA는 품질(Quality) 부서만의 독단적인 이니셔티브가 아닙니다. 태스크포스에는 다음과 같은 핵심 이해관계자가 반드시 참여해야 합니다:

품질 / CSV 리드 (스폰서)
IT / 시스템 엔지니어링
제조 / 생산 운영(Operations)
인허가 / 규제 대응(Regulatory Affairs)
주요 시스템별 현업 비즈니스 프로세스 오너(BPO)

부서 간의 명확한 정렬(alignment)이 없다면, 품질팀이 아무리 SOP를 개정해도 다른 모든 부서는 여전히 과거의 CSV 방식 그대로 움직이게 됩니다.

2단계: 위험 프레임워크 재구축 (4~8주차)

시스템 중요도를 ’프로세스 위험(Process Risk)’으로 대체

이것이 바로 CSA 전환에서 가장 중대한 개념적 변화입니다.

전통적인 CSV: “MasterControl은 매우 중요한 시스템이므로, 모든 기능에 대해 대대적인 테스트를 수행해야 한다.”

CSA: “MasterControl의 세부 기능 중, 오작동했을 때 품질, 데이터 완전성(Data Integrity), 또는 환자 안전에 중대한 악영향을 미칠 수 있는 구체적인 기능은 무엇인가?”

MasterControl을 예로 들면 다음과 같이 분류할 수 있습니다:

높은 프로세스 위험 (High process risk):

전자서명 (Electronic signature)
승인 워크플로우 (Approval workflow)
발효일자 통제 (Effective-date control)
관리본 문서 버전 관리 (Controlled document versioning)
감사 추적 (Audit trail)
교육 이수 상태 관리 (Training completion status)

중간 프로세스 위험 (Medium process risk):

결재 경로 알림 (Routing notifications)
워크플로우 리마인더 (Workflow reminders)
검색 기능 (Search functionality)
대시보드 (Dashboards)

낮은 / 비고위험 프로세스 위험 (Low / not high risk):

UI 사용자 환경 설정 (UI preferences)
화면 표시 설정 (Cosmetic settings)
사용자 편의 기능 (Convenience functions)

이제 보증을 위한 노력은 철저히 위험의 수준을 따릅니다. 검색 기능의 사소한 오류는 전자서명 무력화(bypass)와 결코 동일한 결과를 초래하지 않습니다. 테스트 전략은 이러한 위험의 차이를 명확하게 반영해야 합니다.

위험 평가 템플릿 수립

모든 기능에 대해 다음 6가지 요소를 상세히 문서화합니다:

의도된 용도 (Intended use) — 포괄적이고 추상적인 설명이 아닌, 구체적인 운영 진술이어야 합니다. “사용자는 현재 유효한 SOP 버전을 검색하여 확인할 수 있어야 한다”는 유용하지만, “시스템은 검색 기능을 제공해야 한다”는 부적절합니다.
고장 모드 (Failure mode) — 합리적으로 발생 가능한 오작동 시나리오
잠재적 영향 (Potential impact) — 환자 안전, 제품 품질, 데이터 완전성에 미치는 심각도(severity)
위험 분류 (Risk classification) — 높음(High) / 중간(Medium) / 낮음(Low)
기존 통제 수단 (Existing controls) — 역할 기반 접근 제어(RBAC), 사용자 인증, 감사 추적, 상위 시스템 밸리데이션
요구되는 보증 활동 (Required assurance) — 스크립트 기반 테스트 / 비스크립트 테스트 / 공급업체 증거 활용 / 구성(Configuration) 검토

이 템플릿은 향후 구축될 CSA 방법론의 심장부가 됩니다. 테스트 접근법, 문서화의 깊이, AI 적용 가능성 등 모든 후속 의사결정이 이 템플릿으로부터 도출됩니다.

4대 핵심 QMS 문서 개정

문서	변경 사항
밸리데이션 SOP → 소프트웨어 보증 SOP	“밸리데이션(validate)” 용어를 “보증(assure)“으로 대체. 위험 등급별 의사결정 로직 추가. 비스크립트, 탐색적(exploratory), 자동화 테스트 공식 허용.
밸리데이션 마스터 플랜(VMP) → 소프트웨어 보증 계획서	위험 등급(Risk Tier) → 보증 방법(Assurance Method) 매트릭스 추가. 의무적인 폭포수형 IQ/OQ/PQ 규정 삭제.
테스트 SOP	세 가지 테스트 방식을 공식 인정. FDA는 “위험에 비례하여 스크립트 및 비스크립트 테스트를 혼합 적용할 것”을 명시적으로 권장함.
공급업체 적격성평가 SOP	공급업체 산출물(Supplier Artifacts) 활용 의무화. SOC 2, ISO 27001, 릴리즈 노트, 자동화 테스트 스위트를 기본 증거로 인정.

3단계: 테스트 수행 방식 혁신 (8~16주차)

세 가지 테스트 접근법

위험 수준	기존 CSV 방식	새로운 CSA 방식	증거 형태
높음 (High)	스크린샷이 첨부된 50개의 스크립트 테스트 케이스	여전히 스크립트 기반이지만, 프로세스 위험 시나리오, 네거티브 테스트(Negative testing), 한계/도전 테스트(Challenge testing)에 집중	실행 스크립트 + 감사 추적(Audit Trail) 내보내기
중간 (Medium)	동일한 50개의 스크립트 반복	비스크립트(Unscripted) / 탐색적(Exploratory) 테스트, 시나리오 기반, 오류 추측(Error-guessing). 공급업체 테스트 결과 활용	화면 녹화 영상, 시스템 로그, 요약 노트
낮음 (Low)	동일한 50개의 스크립트 반복	임의 검증(Ad-hoc verification) + 공급업체 인증서 활용	단 한 줄의 기록: 의도된 용도, 위험도, 테스트 항목 및 수행자

구조화된 탐색적 테스트 (Structured Exploratory Testing)

비스크립트(Unscripted) 테스트가 결코 무계획적이거나 주먹구구식(unstructured)인 테스트를 의미하는 것은 아닙니다. 중간 위험 기능의 경우, 명확한 테스트 차터(Test Charter)를 정의하여 수행합니다:

차터 목표: “사용자가 문서 승인 워크플로우를 우회(circumvent)할 수 있는지 여부를 규명한다.”

테스터는 다음과 같은 시나리오를 심층 탐색합니다: 대체 내비게이션 경로 시도, 브라우저 뒤로 가기 버튼 클릭, 직접 URL 입력 접근, 동시 세션 접속, 워크플로우 진행 도중 권한 변경, 반려된 문서 처리, 만료된 세션 처리 등.

그리고 다음 항목을 기록합니다: 테스트 목표, 테스터 신원, 테스트 환경, 수행한 조치, 관찰 결과, 확보된 증거, 최종 결론.

이러한 접근법은 단순한 정상 경로(happy-path) 중심의 스크립트 테스트가 체계적으로 놓치던 실질적인 결함들을 효과적으로 발견해 냅니다. 또한 이는 FDA가 CSA 프레임워크 하에서 명시적으로 공식 인정한 검증 방식입니다.

중단해야 할 관행 (Stop Doing)

제품 품질에 직접적인 영향을 주지 않는 기능에 대해 소모적인 스크립트 기반 테스트 케이스 작성을 중단하십시오.
모든 일상적인 ‘통과(Pass)’ 단계마다 기계적으로 스크린샷을 캡처하는 행위를 중단하십시오 (오직 일탈이나 복잡한 엣지 케이스에 대해서만 요구).
공급업체가 이미 충분히 입증한 기본 IQ/OQ 단계를 중복 실행하는 것을 중단하십시오.
스크린샷을 종이로 출력하는 관행을 중단하고, 디지털 증거 형태로 보관하십시오.

도입해야 할 실무 (Start Doing)

모든 요구사항을 위험 등급에 매핑하십시오. 오직 고위험 영역에만 완전한 스크립트 커버리지를 적용합니다.
시스템 감사 추적(Audit Trail)을 기본 테스트 증거로 활용하십시오.
자동화 테스트 실행 도구(Test Runner)의 로그를 아카이빙하십시오.
ALM(애플리케이션 수명주기 관리) 도구에서 전자 추적성 매트릭스(RTM)를 직접 내보내십시오.
탐색적 테스트 세션을 비디오 화면 녹화 증거로 기록하십시오.

4단계: 최적 영역에서의 AI 도입 (지속 추진)

AI가 적용되어야 할 영역

‘중간 위험이면서 작업량이 많은(Medium-risk, high-volume)’ 영역이야말로 CSA 프레임워크 하에서 AI가 가장 방어 가능하고 확실한 가치를 제공하는 최적의 지점(Sweet Spot)입니다. 이 작업들은 생략하기에는 너무 중요하지만, 전부 수작업으로 처리하기에는 지나치게 방대한 업무들입니다:

프로세스	AI의 역할	사람의 역할
URS(사용자 요구사항 정의서) 초안 작성	프로세스 설명, FMEA 입력값, 규제 기준을 바탕으로 초기 요구사항 자동 생성	의도된 용도의 정확성 검토, 비판적 사고 기반 논리 추가, 전자서명 날인
요구사항-테스트 매핑 (Traceability)	요구사항을 테스트 케이스에 매핑, 누락 갭(gap) 식별, RTM 초안 생성	RTM 최종 승인, 고위험 갭 조정, 테스트 커버리지 검증
증거 요약 (Evidence Summarization)	테스트 실행 결과 파싱, 로그 요약, 적합/부적합 일탈 요약 초안 작성	비판적 검토 수행, 원시 데이터(Raw data) 대조 검증, Part 11 전자서명 적용
위험 평가 (Risk Assessment)	기능 설명 및 과거 데이터를 바탕으로 위험 등급 제안	최종 위험 등급 판정 및 분류 승인

거버넌스 통제 체계 (The Governance Controls)

AI는 CSA 프레임워크 하에서 GxP 생산 시스템이 아닌 ’간접 / 지원 도구(Indirect / Supporting Tool)’로 분류됩니다. 그러나 여전히 다음과 같은 통제가 필수적입니다:

공급업체 평가(Supplier assessment): SOC 2 인증, 데이터 상주(Data Residency) 보장, 조직의 데이터가 AI 모델 학습에 사용되지 않는다는 계약상 보증.

설치 적격성평가(Installation qualification): 모델 버전 고정(Locking), 시스템 구성 문서화, 프롬프트 라이브러리의 버전 관리. URS 초안 작성에 사용된 모든 프롬프트는 GxP 기록(Record)으로 간주됩니다.

AI 생성 문서에 대한 3대 필수 통제 수단:

감사 추적 (Audit trail): 문서 이력 내에 프롬프트 버전 + 모델 버전 + 생성 일자 + 사용자가 명확히 기록되어야 함
검증 체크리스트 (Verification checklist): 사람 검토자의 서약: “본인은 소스 프로세스 문서 및 위험 평가서와 대조하여 AI 산출물을 검증하였으며, 환각(Hallucination)된 요구사항이 없음을 확인함.”
Part 11 컴플라이언스: AI는 결코 전자서명을 수행할 수 없음. 오직 고유한 계정을 보유한 자격을 갖춘 QA 담당자만이 최종 전자서명을 날인할 수 있으며, 서명 전까지 AI 산출물은 ‘초안(Draft)’ 상태를 유지함.

성능 모니터링 (Performance Monitoring)

측정 가능한 임계값을 정의하고 지속적으로 모니터링해야 합니다:

AI 생성 URS 초안에 대한 사람의 수정률 10% 미만 유지
요구사항-테스트 매핑 정확도 100% 달성
증거 요약에서 중요 발견사항의 누락률 5% 미만 유지

도구가 설정된 임계값을 충족하지 못할 경우, CAPA(시정 및 예방조치)를 트리거하고 도구의 신뢰성을 재평가하며 증거 패키지를 업데이트해야 합니다.

5단계: 조직 재교육 (지속 추진)

5가지 핵심 질문

모든 품질팀 구성원은 다음 5가지 질문을 완전히 내재화해야 합니다:

이 시스템 기능의 의도된 용도(intended use)는 무엇인가?
합리적으로 발생할 수 있는 오류나 오작동은 무엇인가?
오작동이 발생했을 때 어떤 결과가 초래되는가?
우리에게 확신을 줄 수 있는 증거는 무엇인가?
왜 이 증거만으로 충분하다고 판단할 수 있는가?

이것이 바로 CSA적 사고 모델(mental model)입니다. 이는 “우리 회사 SOP에 147개의 테스트 스크립트를 실행하라고 적혀 있기 때문”이라는 과거 CSV식 사고방식을 완벽히 대체합니다.

교육해야 할 핵심 역량

비판적 사고 (Critical thinking): 테스트 스크립트를 작성하기 전에 항상 “왜?“를 묻는 훈련. 그 답이 환자 안전, 제품 품질, 또는 데이터 완전성과 직결되지 않는다면, 굳이 공식적인 스크립트 작성이 필요하지 않을 가능성이 높습니다.
탐색적 테스트 기법 (Exploratory testing techniques): 경직된 스크립트 없이도 소프트웨어를 심층 탐색하면서 동시에 객관적 증거를 온전히 확보하는 방법.
위험 평가 방법론 (Risk assessment methodology): FDA 실사관(Investigator) 앞에서 특정 기능을 “비고위험 프로세스 위험(not high process risk)“으로 분류한 논리를 당당히 방어하는 방법.
AI 산출물 평가 역량 (AI output evaluation): AI가 생성한 요구사항 및 추적성 매트릭스에서 환각(Hallucination) 오류를 정확히 짚어내는 방법.
실사 준비 태세 (Audit readiness): 단순히 모든 테스트 스크립트가 완료되었음을 보여주는 것이 아니라, 시스템이 의도된 용도에 완벽히 부합(fit for intended use)함을 입증하는 방법.

조직 문화적 장벽 (The Cultural Barrier)

이것이 전환 과정에서 가장 어려운 부분입니다. 과거의 CSV 관행은 팀들에게 ’문서의 분량’을 곧 ’보증의 수준’과 동일시하도록 길들였습니다. 200페이지짜리 밸리데이션 보고서는 심리적 안정감을 줍니다. 반면 10페이지짜리 보증 기술서(assurance statement)는 왠지 모를 불안감을 줍니다 — 비록 그 10페이지짜리 문서가 200페이지의 스크린샷 뭉치보다 훨씬 더 깊이 있는 비판적 사고를 담고 있음에도 불구하고 말입니다.

품질 리더십은 이러한 전환 과정에서 팀들을 적극적으로 코칭해야 합니다. 패러다임의 재정의가 필요합니다. 성공의 척도는 “우리가 모든 것을 빠짐없이 테스트했는가?“가 아니라, **“이 시스템이 안전하게 작동한다는 객관적 확신을 확보했는가?”**입니다.

6단계: 파일럿, 측정, 확장

단일 시스템 선정

수명주기 이벤트(업그레이드, 신규 모듈 도입, 정기 검토 등)가 예정되어 있는 ‘중간 위험 시스템’ 하나를 선정하십시오. 처음부터 고위험 제조실행시스템(MES)으로 시작하지 마십시오. 전체 시스템 포트폴리오를 한꺼번에 전환하려고 욕심부리지 마십시오.

선정된 시스템에 전체 CSA 워크플로우를 완벽히 적용해 보십시오:

의도된 용도 문서화 (기능 클러스터당 1페이지)
프로세스 오너 및 QA가 참여하는 기능 수준의 위험 평가 워크숍 진행
위험 등급별 소프트웨어 보증 계획서 수립
중간 위험 기능에는 비스크립트 테스트를, 고위험 기능에는 스크립트 테스트를 실행
디지털 증거 패키지 구축

성과 지표 측정

지표	예상 변화 방향
밸리데이션 소요 주기 시간 (Validation cycle time)	40~60% 단축
문서 분량 (Documentation volume)	50~70% 감소
UAT에서 발견된 중대 결함 수	유지 또는 증가 (개선)
운영 환경으로 유출된 결함 수	유지 또는 감소 (개선)
팀 업무 만족도	대폭 향상
감사 대응 자신감 (Audit readiness confidence)	대폭 향상

단계적 확장

파일럿 프로젝트가 성공하고 사내 품질 이해관계자들의 승인을 획득한 후, 다른 중간 위험 시스템들로 점진적으로 대상을 확대하십시오. 팀의 역량이 충분히 숙련되면, 저위험 시스템(더욱 간소화된 방식 적용)과 고위험 시스템(더욱 엄격하지만 여전히 위험에 기반한 방식 적용)으로 프레임워크를 최적화하여 조직 전체로 확장하십시오.

결론 및 핵심 요약

CSV에서 CSA로의 전환은 기존 밸리데이션 문서를 다시 쓰는 단순한 재밸리데이션 작업이 아닙니다. 이는 품질 거버넌스와 의사결정 모델 자체를 근본적으로 바꾸는 체질 개선입니다. 이 전환을 올바르게 완수한 조직은 밸리데이션된 시스템을 훨씬 신속하게 배포하고, 실제 치명적인 결함을 더 많이 찾아내며, 실사 대응에 대한 불안감을 해소하게 될 것입니다. 그들의 증거 패키지가 단순한 체크리스트식 요식 행위가 아니라 진정한 ’비판적 사고’를 입증하기 때문입니다.

대다수 조직이 빠지는 함정은 CSA를 “단지 AI를 도입하고 스크린샷 몇 장 줄인 CSV” 정도로 가볍게 취급하는 것입니다. 진정한 전환은 품질팀이 위험을 바라보는 시각을 새롭게 정의하는 것에서 시작되며, 테스트를 설계하고 실행하는 방식을 혁신하는 것으로 이어집니다. 그리고 CSA의 위험 기반 모델이 방어 가능하게 만든 ‘중간 위험·대량 업무’ 영역에 AI를 강력한 가속기로 도입하는 것은 바로 그 이후의 단계입니다.

SOP 개정에서 출발하십시오. 위험 프레임워크를 구축하십시오. 단 하나의 시스템으로 파일럿을 실행하십시오. 정량적 결과를 측정하십시오. 그리고 확장하십시오.

이것이 바로 CSA 전환을 성공으로 이끄는 확실한 플레이북입니다.

연구 노트: [[CSV to CSA Transition - Comprehensive Compiled Report]]

GxPChat