Palantir for Individuals - Trust, Privacy, and Risk

날짜: 2026-03-14
상태: Draft
문서 목적: 이 제품의 가장 큰 비기능 요구사항인 trust, privacy, safety를 제품 요구사항으로 고정한다.

1. 왜 이 문서가 중요한가

이 제품은 생산성 도구처럼 보일 수 있지만, 실제로는 사용자의 일정, 메일, 재무, 건강, 관계 신호를 한곳에 모으는 고민감도 시스템이다.

신뢰는 부가 기능이 아니라 핵심 기능이다.

외부 신호도 이 점을 뒷받침한다.

Cisco 2024 Consumer Privacy Survey에 따르면 75%는 자신의 데이터를 신뢰하지 않는 조직으로부터 구매하지 않겠다고 답했고, 78%는 조직이 AI를 윤리적으로 사용해야 할 책임이 있다고 봤다.
같은 보고서 PDF에서는 privacy practices가 구매 결정에 영향을 미치고, AI가 유용하더라도 책임 있는 처리 기대가 강하다고 설명한다. 또한 regular Gen AI users 중 45%는 안전한 AI 도구를 일부러 고르고, 45%는 개인 또는 기밀 정보를 입력하지 않는다고 답했다.
Pew Research의 2023 data privacy 조사에서는 AI를 알고 있는 미국인 중 70%가 기업이 AI 사용을 책임감 있게 결정할 것이라고 거의 신뢰하지 않는다고 답했다.
Pew Research의 2025 AI views 조사에서는 대중이 AI의 일자리 상실과 인간적 연결 약화에 대해 전문가보다 더 큰 우려를 보였고, privacy/security도 주요 우려로 등장한다.

즉, 사용자는 AI의 효용을 인정하면서도 동시에 매우 경계한다. 이 제품은 똑똑해 보이는 것보다 믿을 수 있는 것이 중요하다.

2. 기본 원칙

2.1 Control by default

사용자는 무엇을 연결했고, 어디에 쓰였고, 무엇이 저장되는지 항상 알아야 한다.

2.2 Citation before confidence

강한 답변보다 강한 근거가 먼저다.

2.3 Separate facts from inference

관찰 사실, 추정, 추천을 반드시 구분해서 보여준다.

2.4 Sensitive domains need narrower claims

재무, 건강, 관계 관련 판단은 특히 신중한 언어가 필요하다.

2.5 Reversible trust

연결, 삭제, 내보내기, 기억 제거가 쉬워야 한다.

3. Product Requirements

3.1 Source-level controls

연결 단위는 앱 전체가 아니라 가능한 한 source 단위여야 한다.

예:

Gmail 연결
Calendar 연결
특정 노트 저장소 연결
특정 health source 연결

3.2 Memory controls

OpenAI Memory 발표는 memory를 켜고 끄거나 Temporary Chat를 쓰는 제어권이 중요하다고 강조한다. 개인용 운영 시스템도 비슷하게, 기억과 추론 레이어를 사용자가 제어할 수 있어야 한다.

최소 요구사항:

source disconnect
per-item delete
derived memory delete
temporary session
retention window control

3.3 Evidence visibility

각 memo의 주요 주장 옆에는 다음이 있어야 한다.

source count
confidence
recentness
assumption 여부

3.4 Auditability

사용자는 적어도 중요한 memo에 대해 다음 질문에 답을 볼 수 있어야 한다.

어떤 데이터가 이 결론에 쓰였는가
어떤 데이터는 쓰이지 않았는가
무엇이 사실이고 무엇이 추정인가
가장 불확실한 가정은 무엇인가

4. Data Classification

이 제품은 데이터 민감도를 최소 세 층으로 나눠야 한다.

Level 1. Operational

tasks
calendar events
project notes
lightweight relationship metadata

Level 2. Sensitive Personal

email content
financial events
private journal
relationship notes

Level 3. High Sensitivity

health data
biometrics
therapy-like notes
legal / tax records

초기 V1은 Level 1과 일부 Level 2에 집중하고, Level 3는 후순위로 미루는 것이 맞다.

5. Recommended Scope Boundaries

초기 포함

calendar
work email context
notes / docs
tasks
lightweight relationship signals

초기 제외 또는 엄격 제한

medical advice
mental health diagnosis
tax/legal guidance
autonomous financial recommendations
always-on passive recording

특히 Limitless 사례는 항상 켜져 있는 개인 recording 모델이 제품 차별화 포인트가 될 수는 있어도, 지역 지원과 운영 리스크가 매우 크다는 점을 보여준다. Limitless의 2025년 12월 5일 공지에서 신규 Pendant 중단과 일부 국가 지원 종료가 명시된 것은 이 범주의 운영 난도를 보여주는 신호다.

6. UX Requirements for Trust

6.1 Memo structure

모든 memo는 같은 trust skeleton을 가져야 한다.

현재 상태
근거
제약
옵션
예상 변화
불확실성
다음 질문

6.2 Language rules

단정형 예언 금지
과도한 심리 해석 금지
medical/legal/financial authority tone 금지
recommendation에는 반드시 rationale 동반

6.3 Failure handling

데이터가 부족하거나 충돌하면, 답을 꾸미지 말고 아래처럼 동작해야 한다.

부족한 source를 명시
confidence 하향
추가 확인 질문 제시
no-answer 허용

7. Technical Requirements

7.1 Provenance everywhere

ontology와 schema에서 이미 다뤘듯, 주요 entity와 memo output에 source, confidence, observed_at이 있어야 한다.

7.2 Deterministic layer first

runway, schedule conflict, activity density, follow-up lag 같은 것은 LLM 추론보다 deterministic calculation으로 우선 계산해야 한다.

7.3 Safe defaults for retention

기본 보관 기간과 삭제 정책을 명확히 가져가야 한다.

7.4 Export and deletion

사용자는 다음을 기대한다.

raw export
derived export
source disconnect
account-level deletion

8. Risk Register

Risk 1. Creepy factor

문제:

제품이 "너를 너무 많이 안다"는 인상을 주면 바로 거부된다.

대응:

사용자가 이미 제공한 정보에 집중
예측보다 정리/브리핑 톤 유지
surprise minimization

Risk 2. Overreach

문제:

재무/건강/관계에 대해 과도하게 확신 있는 조언을 할 수 있다.

대응:

domain-specific language guardrails
confidence gating
escalation to human or external expert prep mode

Risk 3. Data breach or misuse anxiety

문제:

실제 침해가 없더라도 불안만으로도 도입이 막힐 수 있다.

대응:

clear privacy architecture
explainability
explicit controls
enterprise-style trust surface

Risk 4. Wrong but plausible memos

문제:

가장 위험한 실패 형태다.

대응:

evidence citation
structured assumptions
factual/derived split
post-hoc correction loop

9. Recommended Product Posture

이 제품의 trust posture는 다음 문장으로 정리할 수 있다.

우리는 당신을 대신해 판단하는 블랙박스를 만들지 않는다.
당신의 데이터를 구조화하고, 현재 상태를 계산하고, 선택지를 더 선명하게 브리핑하는 시스템을 만든다.

10. Launch Implications

trust 요구사항은 launch 전략에도 영향을 준다.

open public beta보다 guided onboarding이 낫다
broad consumer marketing보다 founder/operator wedge가 낫다
"remember everything"보다 "brief your decisions"가 낫다

11. 추천 결론

이 제품은 privacy page가 있어서 신뢰를 얻는 종류가 아니다. 제품 구조 자체가 trust를 드러내야 한다.

따라서 source control, evidence visibility, fact vs inference split, reversible memory, narrower claims in sensitive domains는 nice-to-have가 아니라 core product requirement다.