로컬 AI 에이전트는 기업 워크플로에서 GDPR과 호환됩니까?

로컬 AI 에이전트는 아키텍처적으로 GDPR과 호환되지만 기본적으로 GDPR 준수 상태는 아닙니다. 아키텍처는 클라우드 LLM 위협 모델을 제거합니다. Schrems II가 없고, 하위 처리자 목록이 없으며, 국경 간 이전 영향 평가도 없습니다. 모델, 도구 서버, 데이터 모두 컨트롤러의 인프라 내에 있기 때문입니다. 남은 작업은 개인 데이터를 처리하는 모든 시스템에 적용되는 GDPR 통제입니다. 법적 근거(제6조), 데이터 최소화(제5조), 목적 제한(제5조), 처리 보안(제32조), 감사 로그, 그리고 워크플로가 사람에게 큰 영향을 미칠 때 필요한 DPIA(제35조)가 여기에 해당합니다. EU AI Act는 두 번째 레이어를 추가합니다. 대부분의 기업 워크플로는 제한적 위험(투명성 의무만)이며, HR 선별 및 신용 결정은 고위험(전체 적합성 평가)이고, 일부 패턴(직장 내 감정 인식, 사회적 점수제)은 금지됩니다. 로컬 스택 구축은 쉬운 부분입니다. 통제를 문서화하고 DPIA를 실행하는 것이 실제 작업입니다.

홈/고급 로컬 LLM/비즈니스 워크플로를 위한 로컬 AI 에이전트: EU 규정 준수 가이드 2026

Local AI Agents & Tool Use

비즈니스 워크플로를 위한 로컬 AI 에이전트: EU 규정 준수 가이드 2026

최종 업데이트: 2026년 5월 7일·14분 분량·Hans Kuepper 저 · PromptQuorum 창립자, 멀티 모델 AI 디스패치 도구 · PromptQuorum

언어 선택:

🇺🇸en 🇩🇪de 🇫🇷fr 🇯🇵ja 🇨🇳zh 🇪🇸es 🇧🇷pt 🇸🇦ar 🇰🇷ko

로컬 AI 에이전트는 아키텍처적으로 GDPR과 호환됩니다. 단, 모델, 도구 서버, 감사 로그, 벡터 저장소 등 전체 스택이 데이터 컨트롤러의 인프라 내에서 실행되고 데이터가 외부로 유출되지 않을 때만 그렇습니다. 프로덕션에서 수요의 대부분을 충족하는 5가지 기업 워크플로가 있습니다. 문서 수집 및 분류, 이메일 분류와 초안 작성, 회의록 요약과 액션 아이템 추출, 규정 준수 보고서 생성, 청구서 처리와 주문 대조입니다. 각 워크플로는 EU AI Act 하에서 다른 분류를 받습니다. 대부분은 제한적 위험이며, HR 선별은 고위험이고, 금지된 템플릿은 없습니다. 또한 각각 다른 DPIA 기준점을 가집니다. 권장 스택은 Gemma 4 27B / GLM-4.7 32B / Qwen3 32B(tool-calling 지원 모델)를 제공하는 Ollama 또는 vLLM이며, 에이전트 런타임으로 Cline 또는 Goose+MCP, 불변 감사 로그, 그리고 모든 쓰기 또는 전송 작업에 대한 인간 승인이 포함됩니다. 가장 흔한 세 가지 실수는 DPIA 없이 배포하는 것, 단일 워크스페이스에서 개인 데이터와 업무 데이터를 혼합하는 것, 전송 작업에서 승인 게이트를 생략하는 것입니다.

로컬 AI 에이전트는 EU 내 규정 준수를 실질적으로 단순화합니다. 모델, 도구 서버, 데이터 모두 자체 인프라 내에 위치하면 클라우드 LLM 위협 모델이 사라집니다. Schrems II, 하위 처리자 목록, 국경 간 데이터 이전 영향 평가가 더 이상 적용되지 않습니다. 실제 작업은 여전히 유효한 규정으로 이동합니다. 처리하는 데이터에 대한 GDPR 통제, 자동화된 워크플로의 EU AI Act 분류, 직원 데이터 또는 기밀 데이터를 처리하는 워크플로에 대한 지역별 요건(DACH: 사업장 협의회, §203 StGB)이 여기에 해당합니다. 이 가이드는 프로덕션에 즉시 사용 가능한 5가지 워크플로 템플릿, 각 템플릿에 필요한 통제, 그리고 감사에도 견딜 수 있는 모델 및 스택 선택 방법을 다룹니다.

슬라이드 덱: 비즈니스 워크플로를 위한 로컬 AI 에이전트: EU 규정 준수 가이드 2026

이 프레젠테이션은 다음을 다룹니다: EU 준수 로컬 AI 에이전트를 위한 5가지 프로덕션 워크플로 템플릿(문서 수집, 이메일 분류, 회의록 요약, 규정 준수 보고서, 청구서 처리), EU AI Act 하의 위험 분류(제한적 위험 vs. 고위험 vs. 금지), 6가지 GDPR 통제(법적 근거, 데이터 최소화, DPIA), DACH 특수 사항(사업장 협의회 BetrVG §87, §203 StGB 직업 기밀 유지), 모델 선택 표, 그리고 5가지 흔한 배포 실수. PDF를 EU AI 규정 준수 참조 카드로 다운로드하십시오.

아래 슬라이드를 탐색하거나 오프라인 참조용으로 PDF를 다운로드하십시오. 참조 카드 다운로드(PDF)

비즈니스 워크플로를 위한 로컬 AI 에이전트: EU 규정 준수 가이드 2026

핵심 요점

로컬 아키텍처는 가장 강력한 프라이버시 통제입니다. 모델, 도구 서버, 데이터가 컨트롤러의 인프라 내에서 데이터 유출 없이 운영될 때 클라우드 LLM 위협 모델이 사라집니다. Schrems II, 하위 처리자 목록, 국경 간 이전 영향 평가가 더 이상 적용되지 않습니다.
5가지 워크플로 템플릿이 프로덕션 수요의 대부분을 충족합니다: 문서 수집 및 분류, 이메일 분류와 응답 초안 작성, 회의록 요약과 액션 아이템 추출, 규정 준수 보고서 생성, 청구서 처리와 주문 대조. 각 템플릿에는 정의된 데이터 분류, 법적 근거, AI Act 등급, 감사 로그 형식이 있습니다.
EU AI Act 등급이 의무 사항을 결정합니다. 대부분의 기업 워크플로는 제한적 위험(AI가 관여함을 사용자에게 투명하게 알림)에 해당합니다. HR 선별, 신용 결정, 급여 자격은 고위험으로 전체 적합성 평가가 필요합니다. 직장 내 감정 인식과 사회적 점수제는 금지됩니다.
GDPR 작업은 로컬 운영 시에도 변하지 않습니다. 법적 근거(제6조), 데이터 최소화(제5조), 처리 보안(제32조), 감사 로그, 그리고 고영향 워크플로에 대한 DPIA(제35조)가 여전히 적용됩니다. 로컬 스택은 이러한 통제를 입증하기 쉽게 하지만 선택 사항으로 만들지는 않습니다.
DACH는 두 가지 레이어를 추가합니다. 사업장 협의회의 공동 결정(BetrVG §87)은 에이전트가 직원 데이터를 간접적으로라도 처리할 때마다 적용됩니다. §203 StGB 직업 기밀 유지(변호사, 의사, 감사인, 세무사)는 로컬 아키텍처를 선호도가 아닌 필수 요건으로 만듭니다.
참조 스택: Ollama 또는 vLLM이 tool-calling 지원 모델(일반 작업용 Gemma 4 27B, GLM-4.7 32B, Qwen3 32B; 가벼운 이메일 분류용 Llama 3.2 3B)을 제공하고, Cline 또는 Goose+MCP가 에이전트 런타임으로 사용되며, 불변 추가 전용(append-only) 감사 로그와 모든 쓰기 또는 전송 작업에 대한 인간 승인이 포함됩니다.
피해야 할 세 가지 실패 방식: DPIA가 필요한 워크플로를 DPIA 없이 배포하는 것, 단일 에이전트 워크스페이스에서 개인 데이터와 업무 데이터를 혼합하는 것, 발신 작업(이메일 전송, 계약 서명, 결제 승인)에서 승인 게이트를 생략하는 것.

빠른 사실

아키텍처: Ollama 또는 vLLM + tool-calling 지원 모델 + 에이전트 런타임(Cline 또는 Goose+MCP) + 감사 로그 + RAG 저장소, 모두 컨트롤러의 인프라 내에.
지원하는 워크플로: 문서 수집, 이메일 분류, 회의록 요약, 규정 준수 보고서, 청구서 처리.
5가지 템플릿의 EU AI Act 분포: 제한적 위험 4개, 고위험 1개(HR 선별에 사용될 때), 금지 0개.
DPIA 기준점: 고위험에 대해 의무적이며, 나머지는 제35조 기준에 따라 판단. 대부분의 팀은 특수 범주 데이터를 처리하는 워크플로에 대해 실행해야 합니다.
하드웨어 크기 조정: Gemma 4 27B 및 Qwen3 32B는 Q4_K_M에서 24GB VRAM에 맞습니다; GLM-4.7 32B 및 Llama 3.3 70B는 무제한 컨텍스트를 위해 48GB 이상이 필요합니다.
감사 로그 보존: GDPR 제30조 처리 활동 기록 요건이 최소 기준입니다. 업종별 규정(금융 서비스, 의료)은 이를 연장합니다. 6년이 대부분의 기업 환경에 대한 안전한 기본값입니다.
비용: API 지출 없음; 하드웨어는 20명 이상의 팀에 대한 기업 AI SaaS 구독과 비교해 6~12개월 내에 상각됩니다.

로컬 AI 에이전트가 기업 팀에게 하는 일

로컬 AI 에이전트는 읽기와 쓰기 작업 사이에 명시적 승인 게이트를 두고 컨트롤러의 인프라 내에서 실행되는 tool-calling 지원 모델입니다. 채팅 어시스턴트도, 워크플로 자동화 도구(n8n, Zapier)도, 파인튜닝된 분류기도 아닙니다. 이는 모델을 시스템에서 작동하는 무언가로 변환하는 레이어입니다.

📍 한 문장으로

로컬 AI 에이전트는 tool-calling 지원 모델 + 도구 표면 + 승인 게이트로, 컨트롤러의 인프라 내에서 완전히 실행되며 유럽 규정 준수를 문서화 작업에서 아키텍처 속성으로 전환합니다.

💬 쉽게 말하면

에이전트는 파일 시스템을 읽고, 데이터베이스를 조회하고, 이메일을 보내거나 내부 API를 호출할 수 있는 모델로, 인간이 쓰거나 전송하는 모든 작업을 승인합니다. 자체 하드웨어에서 모델, 도구, 감사 로그를 실행하면 클라우드 LLM 규정 준수 스택(Schrems II, 하위 처리자 목록, 국경 간 이전 영향 평가) 전체를 단 하나의 아키텍처적 사실로 대체합니다. 네트워크 외부로 아무것도 나가지 않는다는 것입니다. 남은 것은 데이터 자체에 대한 GDPR 통제로, 클라우드든 로컬이든 모든 시스템에 적용됩니다.

정의: 모델 + 도구 표면(파일 시스템, 데이터베이스, 이메일, 캘린더, 내부 API) + 모든 쓰기에 대한 승인 게이트 = 에이전트. 모델이 제안하고, 에이전트 런타임이 실행하며, 인간이 상태를 변경하거나 네트워크를 벗어나는 모든 것을 승인합니다.
자동화 도구와의 차이점. n8n, Zapier, Make.com은 결정론적 워크플로입니다. 명시적인 트리거, 명시적인 분기, 명시적인 액션이 있습니다. 에이전트는 비결정론적입니다. 모델이 입력과 대화 상태에 따라 어떤 도구를 어떤 인수로 호출할지 결정합니다. 경로가 고정되어 있으면 자동화를 사용하고, 경로가 입력에 따라 달라지면 에이전트를 사용합니다.
채팅 어시스턴트와의 차이점. 채팅 어시스턴트는 질문에 답합니다. 에이전트는 작업을 실행합니다. ChatGPT 스타일의 "이 이메일을 요약해줘"는 텍스트를 반환합니다. 에이전트는 받은 편지함을 읽고, 메시지를 분류하고, 응답 초안을 작성하고, 승인을 위해 대기열에 넣습니다. 다른 표면, 다른 위험 프로파일.
"로컬"이 기업 워크플로에 특히 중요한 이유: 데이터 거주지를 증명할 수 있습니다(바이트가 네트워크를 벗어나지 않음), 감사 추적이 종단 간(end-to-end)으로 이루어지며(동일한 로그가 모델 호출, 도구 호출, 결과를 캡처), 체인에 제3자 하위 처리자가 없습니다. 아키텍처가 전체 위험 범주를 제거할 때 규정 준수 논거는 저절로 작성됩니다.
조직에서 로컬 에이전트가 적합한 곳: 개인 데이터(GDPR), 직원 데이터(사업장 협의회), 기밀 제3자 데이터(NDA, §203 StGB), 또는 규제된 비즈니스 데이터(금융, 의료, 법률)를 처리하는 모든 워크플로. 공공 데이터만 처리하는 워크플로에는 로컬 에이전트가 개선을 가져오지 않습니다. 그런 경우에는 클라우드 에이전트가 대체로 더 빠르고 저렴합니다.
이것을 실용적으로 만드는 프로토콜 레이어에 대해서는 MCP로 Ollama를 데이터베이스와 API에 연결하기: 로컬 에이전트 설정 2026을 참조하십시오.

5가지 기업 워크플로 템플릿

이 5가지 템플릿은 기업 팀에서 로컬 에이전트에 대한 프로덕션 수요의 대부분을 충족합니다. 각 템플릿은 트리거 → 도구 → 모델 권장 사항 → 승인 패턴 → AI Act 등급으로 설명됩니다.

📍 한 문장으로

5가지 템플릿은 트리거와 출력이 다르지만 하나의 규칙을 공유합니다: 읽기 단계는 자동으로 승인되고, 쓰기 또는 전송 단계는 인간 승인이 필요하며, 모든 작업은 불변 감사 로그에 기록됩니다.

💬 쉽게 말하면

이미 수동으로 수행하는 워크플로와 일치하는 템플릿을 선택하십시오. 에이전트가 입력(파일 시스템, 받은 편지함, 스크립트 폴더)을 읽고, 분류하거나 초안을 작성한 다음, 아무것도 전송하거나 쓰기 전에 인간 검토를 기다리도록 연결하십시오. 승인 게이트는 유용한 에이전트와 규제 사고 사이의 차이입니다.

1. 문서 수집 및 분류. 트리거: PDF 또는 스캔이 감시 폴더 또는 이메일로 도착. 도구: 파일 시스템(읽기), OCR(필요시), 분류 모델, 데이터베이스(쓰기). 모델: tool-calling 및 구조화된 출력을 위한 Gemma 4 27B 또는 Qwen3 32B. 승인 패턴: 읽기 및 분류는 자동, 문서에 개인이 언급된 경우 라우팅은 수동. AI Act 등급: 제한적 위험. DPIA: 기준에 따라 판단.
2. 이메일 분류와 응답 초안 작성. 트리거: 모니터링되는 받은 편지함에 새 메시지 도착. 도구: IMAP/Graph API(읽기 전용), 분류 모델, 초안 저장소(쓰기), 알림. 모델: 분류에는 Llama 3.2 3B로 충분, 초안 생성에는 Gemma 4 27B. 승인 패턴: 분류 및 초안은 자동, 전송은 수동(항상). AI Act 등급: 제한적 위험. DPIA: 기준에 따라 판단; 받은 편지함이 직원 데이터를 처리하면 의무적.
3. 회의록 요약과 액션 아이템 추출. 트리거: 스크립트가 저장소에 도착(Whisper 또는 제공업체). 도구: 파일 시스템(읽기), 요약 모델, 추출 모델, 출력 대상(API를 통한 Notion/Jira/내부 위키). 모델: 한 시간짜리 스크립트에서 긴 컨텍스트(128K)를 위한 Qwen3 32B. 승인 패턴: 요약은 자동, 외부 시스템에 게시되는 액션 아이템은 수동. AI Act 등급: 제한적 위험; 각 스크립트를 처리하기 전에 동의 캡처를 확인하십시오.
4. 규정 준수 보고서 생성. 트리거: 예약됨(월별, 분기별). 도구: 데이터베이스(읽기), 보고서 템플릿 저장소, 보고서 렌더러, 검토자 알림. 모델: GLM-4.7 32B 또는 Llama 3.3 70B: 긴 컨텍스트, 구조화된 출력, 낮은 환각. 승인 패턴: 데이터 추출은 자동, 게시된 보고서는 수동. AI Act 등급: 제한적 위험; 기본 데이터 소스에 문서화된 법적 근거가 있는지 확인하십시오. 보고서 형식을 안정적으로 유지하려면 구조화된 출력과 JSON 모드와 결합하십시오.
5. 청구서 처리 및 검증. 트리거: 청구서가 재무 받은 편지함 또는 AP 폴더에 도착. 도구: 파일 시스템(읽기), OCR, ERP 통합(주문 및 공급업체 읽기), 예외 큐(쓰기). 모델: tool-calling을 위한 Gemma 4 27B; 비표준 레이아웃의 청구서에는 Qwen3 32B. 승인 패턴: 추출 및 주문 대조는 자동, 모든 예외(불일치, 새 공급업체, 높은 금액)는 수동. AI Act 등급: 제한적 위험. DPIA: 일반적으로 적용되지 않음.
5가지 전체의 공통 패턴: 읽기 단계는 자동으로 승인되고, 외부 시스템이나 개인의 권리에 영향을 미치는 쓰기 단계는 수동으로 승인됩니다. 감사 로그는 모든 결정을 캡처합니다.

💡Tip: 5개 전부가 아니라 하나로 시작하십시오. 문서 수집과 이메일 분류는 위험이 가장 낮은 두 진입점입니다. 둘 다 제한적 위험이고, 둘 다 명확한 승인 경계(라우팅, 전송)가 있으며, 둘 다 나머지 세 개에서 재사용할 감사 로그 인프라를 구축합니다. 단계적 도입이 규정 준수 팀에 대한 병렬 배포보다 우월합니다.

기업 에이전트에 대한 EU AI Act 분류

EU AI Act는 기술적 정교함이 아니라 기본권에 대한 위험에 따라 AI 시스템을 분류합니다. 동일한 모델과 스택이 제한적 위험 및 고위험 워크플로를 모두 제공합니다. 의무는 기술이 아닌 사용에 적용됩니다.

제한적 위험(대부분의 템플릿): 투명성 의무. AI가 생성한 이메일이나 요약을 받는 사용자는 AI가 관여했음을 알아야 합니다. 메시지의 명확한 표시와 최종 사용자용 시스템 문서의 공개 행이면 충분합니다. 적합성 평가는 필요하지 않습니다.
고위험(특정 사용 사례): 전체 적합성 평가, EU 데이터베이스 등록, 시판 후 모니터링, 일부 하위 범주에서 공인 기관. 기업 팀에서 고위험에 도달하는 패턴은 HR 선별(이력서 분류, 지원자 점수), 신용 결정, 급여 자격, 공공 서비스 접근입니다. 규정의 부록 III이 운영 목록입니다.
금지됨(배포하지 말 것): 공공장소에서의 실시간 생체 인식(법 집행에 대한 좁은 예외 포함), 자연인의 사회적 점수제, 취약성을 대상으로 한 조작적 기술, 직장 내 감정 인식(제한적인 의료/안전 예외 포함), 프로파일링 기반 예측적 치안 유지.
5가지 템플릿에 대한 실용적인 워크플로 → 등급 매핑: 문서 수집(제한적 위험), 이메일 분류(제한적 위험), 회의록 요약(제한적 위험; 동의 확인), 규정 준수 보고서(제한적 위험), 청구서 처리(제한적 위험). 5가지 기본 템플릿은 모두 제한적 위험입니다. 동일한 템플릿을 HR 선별이나 신용 결정으로 재사용하면 사용을 통해 고위험 의무를 상속받습니다.
공급업체 vs. 운영자 구분이 중요합니다. 모델을 제3자에게 판매되는 제품에 통합하면 공급업체입니다(더 많은 의무). 자체 이름으로 시스템을 운영하면 운영자입니다(의무가 적지만 실제로 존재). 내부용 전용 로컬 에이전트는 일반적으로 운영자로 만듭니다.
모든 새 워크플로에 대한 조치 항목: 배포를 승인하기 전에 분류하십시오. 분류는 서면 근거를 가진 일회성 결정(제한적 위험 / 고위험 / 금지)으로, DPO 또는 규정 준수 책임자가 서명하고 AI 시스템의 기술 파일에 보관됩니다.

📌Note: EU AI Act 부록 III의 고위험 사용 사례 목록이 운영 참조입니다. 워크플로를 분류할 때 직접 참조하십시오. 요약 기사에 의존하지 마십시오. 법적 텍스트는 체크리스트로 사용하기에 충분히 간결하고 정확합니다.

독일: 사업장 협의회 공동 결정 및 §203 StGB

DACH 워크플로에는 영어 가이드가 자주 놓치는 두 가지 추가 레이어가 있습니다. 둘 다 조기에 적용되며, 생략하면 둘 다 결정을 차단합니다.

사업장 협의회 공동 결정(BetrVG §87(1) Nr. 6). 직원의 행동이나 성과를 모니터링하는 모든 기술 시스템은 공동 결정을 적용합니다. 독일 노동 법원은 "모니터링"을 광범위하게 해석합니다. 직원 이메일을 분류하거나 직원 회의를 요약하는 에이전트도 해당됩니다. 사업장 협의회는 배포 후가 아닌 설계 시점에 참여해야 합니다. 이 단계를 생략하면 에이전트 배포가 나중에 무효화될 수 있습니다.
실용적 의미: 직원 데이터를 간접적으로라도 처리하는 워크플로를 배포하기 전에, 출력이 직원 자신에게 즉각적으로 이익이 되는 경우에도, 사업장 협의회를 참여시키십시오. 계약(Betriebsvereinbarung)은 시스템의 기술 파일 일부가 됩니다. 대부분의 사업장 협의회는 조기에 참여시키면 건설적입니다. 늦게 참여시키면 거의 그렇지 않습니다.
§203 StGB 직업 기밀 유지. 변호사, 의사, 감사인, 세무사, 그 밖의 특정 직업은 고객 정보의 무단 공개에 대해 형사 책임을 집니다. "보조자"(§203(3))에 대한 예외는 내부 직원을 커버하지만 외부 서비스 제공업체를 자동으로 커버하지는 않습니다. 클라우드 LLM은 외부 서비스 제공업체입니다. 이것이 §203 적용을 받는 사무소가 로컬 스택으로 이전한 법적 핵심입니다.
실용적 의미: §203에 구속되는 모든 직업에 대해 로컬 아키텍처는 선호도가 아니라 워크플로가 존재할 수 있게 하는 기본 요건입니다. 에이전트 제공업체와의 계약(있는 경우)은 §203 준수 조항을 포함해야 합니다. 기술 파일은 고객 데이터가 사무소 인프라를 벗어나지 않음을 문서화해야 합니다.
오스트리아 및 스위스: 오스트리아는 §203(StGB §121)과 밀접하게 반영됩니다. 스위스 기밀 유지(StGB CH 제321조)는 더 광범위합니다. 아키텍처 결론은 동일합니다: 기밀 전문 데이터에 대한 예외 없는 순수 로컬.
동일한 컨트롤러 측의 데이터 규정 준수 환경에 대해서는 개인 비즈니스 데이터를 위한 로컬 RAG를 참조하십시오. RAG 및 에이전트 스택은 감사 로그 및 접근 제어 레이어를 공유합니다.

⚠️Warning: 배포 시점이 아닌 설계 시점에 사업장 협의회를 참여시키십시오. 독일 노동 법원은 사전 Betriebsvereinbarung 없이 직원 데이터를 처리한 에이전트 배포를 무효화했습니다. 사업장 협의회를 조기에 참여시키는 비용은 몇 시간입니다. 늦게 참여시키는 비용은 더 약한 협상 위치에서 일시 중지된 배포와 재협상입니다.

기업 에이전트에 적합한 모델 선택

tool-calling 신뢰성은 하네스가 아닌 모델의 속성입니다. 동일한 하네스가 소형 범용 모델과 결합하면 실패하고, 27B 이상의 tool-calling에 맞게 조정된 모델과 결합하면 작동합니다. 먼저 모델을 선택하십시오.

**Gemma 4 27B (gemma4:27b).** 2026년 5월 범용 tool-calling의 최고 모델. Q4_K_M에서 통합 메모리 16GB 또는 VRAM 24GB에 맞습니다. 문서 수집, 이메일 분류, 청구서 처리에 신뢰할 수 있습니다. 연쇄 도구 호출에서 다소 보수적인데, 이는 어차피 모든 단계에 명시적 승인이 있는 기업 워크플로에 잘 맞습니다.
**GLM-4.7 32B (glm5:32b).** 기본 제공 128K 컨텍스트. 강력한 tool-calling 신뢰성. 긴 입력이 있는 규정 준수 보고서 및 회의록 요약을 위한 선택. Q4_K_M에서 무제한 컨텍스트를 위해 24GB 이상의 VRAM 필요.
**Qwen3 32B (qwen3:32b).** 균형 잡혔고, 다단계 계획에서 매우 신뢰할 수 있습니다. Gemma 4가 너무 보수적일 때 좋은 대안. 기본 제공 32K 컨텍스트; 대부분의 기업 작업에 충분합니다.
**Llama 3.3 70B (llama3.3:70b).** 더 높은 한계, 더 무거운 하드웨어. Q4_K_M에서 48GB 이상의 VRAM 또는 통합 메모리 64GB. 신뢰성이 속도보다 중요한 규정 준수 보고서 및 예외 관리에 사용하십시오.
**Llama 3.2 3B (llama3.2:3b).** 대용량 분류를 위한 경량 선택. VRAM 8GB에서 편안하게 실행됩니다. "이 이메일이 고객 지원 / 영업 / 스팸인가?"에 충분합니다. 응답 초안 작성에는 충분하지 않습니다. 초안 작성 단계를 위해 27B 이상의 모델과 결합하십시오.
Mistral Large. 순수 로컬이 과도하지만 미국 클라우드가 옵션이 아닌 하이브리드 구성을 위한 EU 호스팅 대안. DPA를 통해 Mistral의 EU 엔드포인트를 통해 실행합니다. 데이터는 EU 관할권에 유지됩니다.
tool-calling 작업에 피해야 할 것: 프로덕션 작업에서 7B 미만인 것, 명시적 tool-calling 훈련 없는 범용 모델, 소형 끝에서 Q4_K_M보다 더 공격적인 양자화. 증상은 잘못 형성된 도구 호출, 환각된 인수, 중단된 에이전트 루프입니다.
비교 데이터는 2026년 tool-calling을 위한 최고의 로컬 모델을 참조하십시오. 동일한 모델로 VRAM 및 하드웨어 크기 조정에 대해서는 2026년 로컬 LLM 하드웨어 가이드를 참조하십시오.

💡Tip: Q4_K_M이 tool-calling 신뢰성을 위한 프로덕션 최소값입니다. Q3 이하는 채팅 품질을 저하시키기 전에 tool-calling 정확도를 저하시키는데, 이는 규제된 워크플로에서 실패하는 잘못된 방식입니다. VRAM이 부족하면 양자화 수준을 낮추기 전에(Q4 → Q3) 매개변수 수준을 낮추십시오(32B → 27B).

기업 사용을 위한 에이전트 스택 비교

2026년 기업 워크플로에 신뢰할 수 있는 에이전트 런타임 4가지가 있습니다. 승인 게이트의 UX, 감사 추적의 풍부함, 각각이 필요로 하는 사용자 정의 코드에서 차이가 납니다.

Cline + Ollama를 선택하십시오 팀이 기술적이고 워크플로가 VS Code 내에 맞으면. 설치 마찰이 적고, 작동하는 에이전트까지 가장 빠른 경로.
Goose + MCP를 선택하십시오 워크플로가 IDE가 없는 서버(예약된 규정 준수 보고서, 폴더를 감시하는 수집기)에서 실행되면.
n8n + Ollama를 선택하십시오 워크플로가 하나 또는 두 개의 모델 단계를 가진 결정론적 형태이면. n8n의 human-in-the-loop 노드는 사용자 정의 UI 없이 승인 게이트를 제공합니다.
LangGraph 사용자 정의를 선택하십시오 워크플로의 형태가 위의 것과 진정으로 호환되지 않을 때만. 구축 노력이 실제입니다. 감사 추적 및 승인 게이트 코드는 직접 처리해야 합니다.
이러한 스택 간의 정직한 신뢰성 비교를 위해 2026년 로컬 AI 에이전트: 실제로 작동하는 것과 아직 실패하는 것을 참조하십시오.

런타임	설정	승인 게이트	감사 추적	최적 용도
Cline (VS Code)	확장 프로그램 설치	단계별, IDE에서; 자동 승인 목록	확장 프로그램 내 로그; 규정 준수를 위해 내보내기 필요	코드 지향 워크플로, 단일 개발자 감사
Goose + MCP	Brew install + mcp.json	CLI 프롬프트; 도구별 구성 가능	CLI 로그 파일; 불변 저장소로 교체	CLI 워크플로, 헤드리스 서버
n8n self-hosted + Ollama	Docker + n8n LLM 노드	워크플로 수준의 human-in-the-loop 노드	n8n 기본 실행 로그 + 데이터베이스	하나 또는 두 개의 모델 단계를 가진 결정론적 형태의 워크플로
LangGraph 사용자 정의 + Ollama	Python 프로젝트, 실제 테스트 스위트	직접 구축(인터럽트 API)	직접 구축	엔지니어링 투자를 정당화하는 프로덕션 워크플로

💡Tip: Cline은 코드 지향이 아닌 워크플로에도 마찰이 가장 낮은 시작점입니다. MCP 서버(파일 시스템, sqlite, IMAP)를 연결하면 오케스트레이터를 작성하지 않고도 단일 런타임에서 문서 수집, 청구서 처리, 이메일 분류를 갖게 됩니다. 워크플로 형태가 Cline의 단계별 UX를 진정으로 넘어설 때만 LangGraph로 마이그레이션하십시오.

EU 기업 워크플로에서 로컬 에이전트 배포 시 흔한 실수

실수 1: DPIA 없이 배포. 특수 범주 데이터를 처리하거나 개인에 대한 결정을 내리는 모든 워크플로에는 DPIA가 필요합니다. DPIA는 간결합니다. 대부분의 에이전트 워크플로에서 4~8페이지입니다. 그러나 의무적이며 감독 기관이 처음에 요청하는 것입니다. 배포 전에 작성하십시오.
실수 2: 기밀 문서에 클라우드 연결 에이전트 사용. 로컬 모델만으로는 충분하지 않습니다. 에이전트 런타임, 감사 로그, 임베딩 저장소가 제3자 클라우드에 있으면 말입니다. 아키텍처는 종단 간입니다. 체인에 단일 클라우드 종속성이 있으면 순수 로컬 논거를 깹니다.
실수 3: 쓰기 또는 전송 작업에 승인 게이트 없음. 에이전트가 읽고, 분류하고, 초안을 작성하고, 전송합니다. 전송 단계는 모델이 얼마나 신뢰할 수 있었는지와 관계없이 인간이 항상 승인해야 하는 것입니다. 자동 전송 에이전트는 규제 기관이 당신을 알게 되는 방법입니다.
실수 4: 단일 워크스페이스에서 개인 데이터와 업무 데이터 혼합. 에이전트의 작업 디렉토리와 벡터 저장소는 워크플로별로 범위가 지정되어야 하며 공유되어서는 안 됩니다. 교차 오염은 목적 제한을 위반합니다. 복구 비용이 많이 듭니다.
실수 5: 감사 로그 생략. "모델의 대화 기록에서 재구성할 수 있다"는 감사 로그가 아닙니다. 추가 전용, 해시 체인, 관련 보존 기간에 따라 유지, 데이터 주체 접근 요청 담당자가 조회 가능: 이것이 최소 기준입니다.

출처

EU AI Act 통합 텍스트 (artificialintelligenceact.eu) — 규정의 공식 추적 집계; 부록 III은 운영 고위험 목록입니다.
GDPR 전체 텍스트 (gdpr-info.eu) — 제5조, 6조, 25조, 32조, 35조는 에이전트 설계에 운영적으로 적용됩니다.
NIST AI 위험 관리 프레임워크 — 유럽이 아니고 구속력이 없지만, GOVERN / MAP / MEASURE / MANAGE 구조는 감사 준비에 유용한 체크리스트입니다.
개인화된 자동 의사 결정에 관한 EDPB 지침 03/2018 — 개인에 대한 결정을 내리는 워크플로에 운영적으로 적용됩니다. GDPR 제22조 및 AI Act 모두에 관련됩니다.
AI 시스템에 관한 BfDI 위치 문서 (독일 연방 데이터 보호 위원 — DACH에 특화; §203 StGB 및 사업장 협의회 관행을 참조합니다.

자주 묻는 질문

로컬 AI 에이전트는 기본적으로 GDPR을 준수합니까?

아니요: 아키텍처적으로 GDPR과 호환되지만 기본적으로 준수 상태는 아닙니다. 순수 로컬 아키텍처는 클라우드 LLM 위협 모델(Schrems II, 하위 처리자 목록, 국경 간 이전)을 제거하지만 데이터 자체에 대한 GDPR 통제는 여전히 적용됩니다. 법적 근거(제6조), 데이터 최소화(제5조), 처리 보안(제32조), 감사 로그, 워크플로가 이를 정당화할 때 DPIA가 여기에 해당합니다. 로컬 스택은 이러한 통제를 입증하기 쉽게 합니다. 선택 사항으로 만들지는 않습니다.

EU AI Act 하에서 어떤 워크플로가 고위험입니까?

부록 III은 운영 고위험 사용 사례를 열거합니다. 기업 팀에 가장 자주 영향을 미치는 패턴은 HR(이력서 선별, 지원자 분류, 성과 평가), 신용 결정, 급여 자격, 필수 서비스 접근입니다. 대부분의 일반 기업 워크플로(문서 수집, 이메일 분류, 회의록 요약, 청구서 처리, 규정 준수 보고서)는 제한적 위험입니다. 투명성 의무만 있고 전체 적합성 평가는 없습니다.

이메일 분류 에이전트에 DPIA가 필요합니까?

경우에 따라 다릅니다. DPIA는 워크플로가 중대한 영향을 미치는 개인 데이터의 체계적인 처리(제35조(1))를 수반하거나 감독 기관의 의무 DPIA 목록에 나타날 때 의무적입니다. 일반 받은 편지함 분류 에이전트는 종종 자동으로 적용되지 않습니다. 동일한 에이전트가 HR 또는 지원자 받은 편지함에 있으면 적용됩니다. 대부분의 팀은 엄격한 적용 기준과 관계없이 직원 데이터를 포함하는 모든 받은 편지함에 대해 간단한 DPIA를 실행해야 합니다. 비용은 몇 시간이고 이익은 문서화된 승인입니다.

로컬 에이전트가 직원 데이터를 처리할 수 있습니까?

예, DACH에서 두 가지 추가 단계가 필요합니다. 첫째, 사업장 협의회 공동 결정(BetrVG §87(1) Nr. 6): 설계 시점에 사업장 협의회를 참여시키고 목적, 보존, 접근, 감사 요건을 정의하는 Betriebsvereinbarung에 서명합니다. 둘째, GDPR 하의 법적 근거: 일반적으로 문서화된 비교 형량을 가진 계약 또는 정당한 이익. 사업장 협의회 단계를 생략하면 독일 노동 법원에서 배포가 나중에 무효화될 수 있습니다.

어떤 모델 크기가 기업 워크플로를 신뢰할 수 있게 처리합니까?

Gemma 4 27B가 범용 tool-calling에 신뢰할 수 있는 기본값입니다. GLM-4.7 32B는 입력이 길 때 선택입니다(규정 준수 보고서, 한 시간짜리 회의록): 기본 제공 128K 컨텍스트. Qwen3 32B는 균형 잡힌 대안입니다. Llama 3.3 70B는 더 높은 한계를 가지지만 48GB 이상의 VRAM이 필요합니다. Llama 3.2 3B는 대용량 분류에 충분하지만 초안 작성에는 충분하지 않습니다. 7B 미만의 모델은 그것을 감싸는 에이전트 런타임과 관계없이 잘못 형성된 도구 호출을 생성합니다.

에이전트가 한 일을 어떻게 감사합니까?

각 에이전트 작업은 로그 항목을 씁니다: 타임스탬프, 사용자/시작자, 모델 식별자 및 버전, 입력 해시, 인수와 함께하는 도구 호출, 출력 해시, 수동 승인이 적용된 경우 승인자. 저장소는 무결성 보호(해시 체인 또는 서명된 로그 행)를 갖춘 추가 전용입니다. 보존은 최소한으로 GDPR 제30조 처리 활동 기록 요건을 따릅니다. 업종별 규정(금융 서비스, 의료)은 이를 연장합니다. 감사 로그는 데이터 주체 접근 요청에 응답하고 단일 형식으로 AI Act 기술 파일에 공급됩니다.

부서 간에 에이전트를 공유할 수 있습니까?

아키텍처적으로는 가능하지만 법적으로는 복잡합니다. 각 부서는 자체 목적, 자체 법적 근거, 자체 보존, 잠재적으로 자체 사업장 협의회 계약을 가집니다. 공유 에이전트는 이 모든 것을 흐리게 하고 목적 제한(제5조(1)(b)) 하에서 교차 오염 위험을 만듭니다. 가장 깔끔한 패턴: 하나의 에이전트 런타임, 워크플로별 별도 워크스페이스, 워크플로별 별도 감사 로그, 기본 모델의 단일 배포. 모델은 공유 리소스입니다. 워크플로는 그렇지 않습니다.

국경 간 자회사의 경우는 어떻습니까?

컨트롤러가 EU 엔티티이고 데이터가 EU 인프라에 유지되면 순수 로컬 아키텍처는 기본적으로 대부분의 국경 간 우려를 커버합니다. 두 가지 경우에 주의하십시오. EU 외부 자회사가 EU 개인 데이터에 대해 로컬 에이전트를 실행하는 경우(데이터는 EU에 유지되어야 합니다. 개인 데이터가 유출되지 않는 한 에이전트는 원격으로 운영될 수 있습니다)와 EU 외부 지원 팀이 에이전트 출력에 접근하는 경우(이전으로 처리합니다. GDPR 제5장 하의 법적 근거를 문서화하십시오). Scaleway의 Mistral Large는 순수 로컬이 과도하고 미국 클라우드가 옵션이 아닐 때 일반적인 하이브리드 선택입니다.

← 고급 로컬 LLM으로 돌아가기