민감 데이터 라우팅

민감 데이터 라우팅 (Sensitive Data Routing, 내장 가드레일)

요청에서 민감 데이터를 감지해 차단하거나 검열하는 대신 온프레미스 모델로 다시 라우팅하는 내장 가드레일이에요. 외부 의존성이 필요 없답니다.

언제 사용하나요? 민감한 프롬프트를 클라우드 프로바이더 대신 온프레미스 모델로 처리해야 하면서도 사용자 워크플로가 중단되지 않아야 할 때 사용해요.

출처: 문서

본문

개요 (Overview)

속성	세부사항
설명	regex/키워드 매칭으로 민감 데이터를 감지하고 요청을 온프레미스 모델로 다시 라우팅. 한 세션에서 민감 데이터가 나타나면 그 세션의 이후 모든 턴도 온프레미스로 라우팅.
가드레일 이름	sensitive_data_routing
감지 방법	사전 구축 regex 패턴, 커스텀 regex, 키워드 매칭
조치	온프레미스 모델로 다시 라우팅 (절대 차단·검열하지 않음)
지원 모드	pre_call
성능	빠름. 로컬에서 실행되며 외부 API 호출 없음

동작 방식 (How it works)

가드레일은 모델 선택 전에 실행돼요. 매 요청마다 구성한 패턴과 키워드로 messages를 스캔해요. 일치 항목이 발견되면 대상 모델을 on_premise_model로 다시 작성해서 요청이 온프레미스에서 처리되게 해요. 프롬프트는 변경 없이 전달되므로 아무것도 차단·검열되지 않고 대화는 정상적으로 계속돼요.

sticky_session이 활성화된 경우(기본값), 세션에서 민감 데이터가 처음 보이면 그 세션은 온프레미스 모델로 고정(pin)돼요. 이후 그 세션의 모든 턴은 민감 데이터가 없어도 온프레미스로 라우팅돼요. 즉 한 번이라도 민감 데이터를 다룬 대화는 절대 온프레미스 모델을 벗어나지 않아요. 고정은 클라이언트가 보내는 안정적인 session id에 의존해요(세션 고정성 참조).

on_premise_model은 단지 model_list의 모델 그룹일 뿐이에요. 실행 중인 온프레미스 배포(vLLM, Ollama, 자체 호스팅 OpenAI 호환 엔드포인트 등)를 가리키면 돼요.

빠른 시작 (Quick Start)

1단계: config.yaml에 가드레일과 온프레미스 모델 정의하기

model_list:
  - model_name: cloud-model
    litellm_params:
      model: openai/gpt-5.6-luna
      api_key: os.environ/OPENAI_API_KEY

  - model_name: on-prem-model
    litellm_params:
      model: hosted_vllm/meta-llama/Llama-3.1-8B-Instruct
      api_base: http://your-on-prem-host:8000/v1

guardrails:
  - guardrail_name: "sensitive-data-routing"
    litellm_params:
      guardrail: sensitive_data_routing
      mode: "pre_call"
      default_on: true

      # The model group (from model_list above) to route sensitive requests to
      on_premise_model: "on-prem-model"

      # Built-in detectors
      prebuilt_patterns:
        - us_ssn
        - credit_card
        - email
      regex_patterns:
        - "project\\s+titan"
      keywords:
        - confidential
        - internal only

      # Keep the whole session on-premise once sensitive data is seen
      sticky_session: true
      session_ttl_seconds: 14400

2단계: 프록시 시작하기

litellm --config config.yaml --detailed_debug

3단계: 깨끗한 요청 보내기 (클라우드 모델이 처리)

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "cloud-model",
    "messages": [{"role": "user", "content": "What is the capital of France?"}],
    "metadata": {"session_id": "abc-123"}
  }'

응답 모델 필드는 클라우드 모델을 반영해요.

4단계: 민감 데이터가 있는 요청 보내기 (온프레미스로 재라우팅)

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "cloud-model",
    "messages": [{"role": "user", "content": "My SSN is 123-45-6789, summarize my record"}],
    "metadata": {"session_id": "abc-123"}
  }'

요청은 on-prem-model이 처리해요. sticky_session이 켜져 있고 같은 session_id를 사용하므로, abc-123에 대한 이후 모든 요청은 민감 데이터가 없어도 온프레미스로 처리돼요.

구성 (Configuration)

파라미터	타입	기본값	설명
on_premise_model	string	필수	민감 요청을 라우팅할 `model_list`의 모델 그룹
prebuilt_patterns	list[string]	없음	매칭할 내장 패턴 이름 (예: `us_ssn`, `credit_card`, `email`). LiteLLM Content Filter와 같은 라이브러리 사용
regex_patterns	list[string]	없음	커스텀 정규식. 어떤 메시지에서든 일치하면 요청 재라우팅
keywords	list[string]	없음	대소문자 무시 키워드. 어떤 메시지에서든 일치하면 요청 재라우팅
sticky_session	bool	true	민감 데이터 최초 감지 후 전체 세션을 온프레미스로 유지
session_ttl_seconds	int	14400	감지 후 세션이 온프레미스로 고정되는 시간

prebuilt_patterns, regex_patterns, keywords 중 하나 이상이 필요해요.

세션 고정성 (Session stickiness)

고정성은 최초 감지 후 세션을 온프레미스 모델로 고정해요. 세션은 요청의 litellm_session_id, metadata.session_id, 또는 litellm_metadata.session_id로 식별되므로, 고정성이 적용되려면 클라이언트가 턴마다 안정적인 id를 보내야 해요.

프록시에 Redis 캐시가 구성되어 있으면 고정은 모든 프록시 워커·인스턴스에 공유되어, 단일 워커가 아니라 전체 배포에 걸쳐 고정성이 유지돼요.

세션 id를 보내지 않으면 각 턴은 여전히 독립적으로 평가되므로, 민감 데이터를 담은 턴 자체는 온프레미스로 라우팅되지만 세션 id가 없는 턴은 대화 전반에 걸쳐 고정되지 않아요.

더 알아보기 (Learn more)

가드레일 문서