Starfort가 필요한 이유: AI 리스크 계층
Starfort가 존재하는 이유는 AI 리스크가 하나의 균질한 문제가 아니기 때문입니다. AI 리스크는 세 단계로 나뉘며 각 단계는 서로 다르게 다루어집니다. 이 순서가 바로 “중앙에서 집행하고, 로컬에서 최적화한다”는 원칙을 정당화합니다.
이는 두 팀의 책임 분담에 대응됩니다. 보안팀이 AI 보안 리스크를 담당하고, AI 거버넌스팀이 서비스/품질 리스크를 담당하며, 두 팀이 규제 리스크를 공동으로 담당합니다. Starfort는 바로 이 협업을 지원하도록 설계되었습니다. 가장 중요한 정책은 중앙에서 집행하되, 각 팀은 품질을 위해 조정할 자유를 유지합니다.
Starfort 사용 방식
세 가지 진입점이 있으며 각각 서로 다른 **통제 수준(level of control)**을 제공합니다. 이들은 동일한 Guardian 엔진과 정책을 공유합니다.API — 서비스 수준
내부/외부 서비스(백엔드, 챗봇)가 모델 호출 전후에 Guard API를 호출하여 가드레일을 내장합니다.
Desktop Agent — 디바이스 수준
직원이 일상적인 AI 도구를 사용하는 동안 Desktop Agent(Windows)가 엔드포인트에서 투명하게 정책을 집행합니다.
Proxy Server — 인프라 수준
외부 서비스의 서버 측 진입점에서 발생하는 AI 호출이 Starfort를 통해 라우팅됩니다.
Guardian이 요청에 하는 일
모든 콘텐츠는 Guard Policy에 대해 평가되어 액션이 부여됩니다. 액션 집합은 정책 유형에 따라 달라집니다.PASS
콘텐츠가 변경 없이 통과합니다.
MASK
민감한 부분이 토큰(예:
[PHONE_NUMBER_1])으로 대체됩니다 — PII 정책.BLOCK
요청이 AI 서비스에 도달하기 전에 중단됩니다.
핵심 개념
Guardian
콘텐츠를 검사하고 액션을 결정하는 엔진입니다.
Guard Policy
Guardian이 집행하는 PII 및 Topic 규칙입니다.
조직 계층
Company › Organization › Project, 그리고 Guardian이 프로젝트에 연결되는 방식입니다.
용어집
이 문서에서 사용되는 모든 Starfort 용어의 정의입니다.
이 문서는 Starfort v1.2를 다룹니다. 제품명 — Starfort, Guardian, Guard Policy, Guard API, Opticon, Control Profile — 은 모든 언어에서 영어로 유지됩니다.