Abliteration.ai는 AI 안전장치를 없애는 회사인가, 아니면 안전 정책의 통제권을 기업으로 이전하는 회사인가?

생성형 AI를 사용하다 보면 위험하지 않은 질문인데도 답변을 거부당할 때가 있습니다.

사이버보안 연구자가 악성코드의 동작을 분석하거나, 의료기관이 민감한 기록을 분류하거나, 기업의 AI 레드팀이 실제 공격 상황을 재현하려는 경우가 대표적입니다. 모델은 사용자의 자격과 목적을 충분히 알지 못하기 때문에 위험과 관련된 표현이 들어갔다는 이유만으로 요청 전체를 차단하기도 합니다.

이런 과잉 거부를 사업 기회로 삼은 곳이 Abliteration.ai입니다.

Abliteration.ai는 오픈웨이트 AI 모델에 학습된 거부 성향을 약화한 뒤 API 형태로 제공합니다. 이용자는 모델을 직접 내려받고 수정하거나, 이를 실행할 고성능 GPU 환경을 마련하지 않아도 상대적으로 제한이 적은 모델을 사용할 수 있습니다.

처음 보면 AI 안전장치를 제거해 주는 위험한 서비스처럼 보입니다. 실제로 ‘가드레일 제거’는 이 회사가 제공하는 제품의 핵심입니다. 하지만 Abliteration.ai는 기업이 별도의 정책 게이트웨이를 통해 허용·차단 기준을 직접 정할 수 있다며 다음과 같이 주장합니다.

Unrestricted. Not ungoverned.
제한은 없지만, 통제가 없는 것은 아니다.

그렇다면 Abliteration.ai는 AI의 안전장치를 없애는 회사일까요? 아니면 모델 기업이 독점하던 안전 정책의 통제권을 실제 사용 기업으로 이전하는 회사일까요?

결론부터 말하면 두 설명 모두 맞습니다.

Abliteration.ai는 모델 내부의 기본적인 거부 성향을 제거해 사업화하는 동시에, 기업 고객에게는 그 빈자리를 조직별 정책으로 다시 채울 수 있는 통제 계층을 제공합니다. 다만 안전 정책을 기업으로 이전한다는 설명이 성립하려면 선택형 정책 도구를 제공하는 것만으로는 부족합니다. 누가 서비스를 이용하는지, 어떤 요청이 실제로 차단되는지, 정책 우회와 오작동에 어떻게 대응하는지까지 검증돼야 합니다.

‘Abliteration’은 무엇을 제거하는가

Abliteration은 제거·절제를 뜻하는 ablation과 완전한 제거를 뜻하는 obliteration을 결합한 표현입니다. AI 모델이 특정 요청에 답변하지 않도록 학습된 거부 성향을 약화하는 기술을 가리킵니다.

이 개념의 기술적 배경으로 자주 언급되는 연구가 2024년 공개된 논문 「Refusal in Language Models Is Mediated by a Single Direction」입니다.

연구진은 여러 오픈 언어모델을 분석한 결과, 유해하다고 판단한 요청을 거부하는 행동이 모델 내부 표현 공간의 특정한 방향과 밀접하게 연결돼 있다고 설명했습니다. 이른바 **거부 방향(refusal direction)**입니다.

원리를 단순화하면 다음과 같습니다.

1. 같은 모델에 정상적인 요청과 거부를 유발하는 요청을 각각 입력합니다.

2. 두 요청을 처리할 때 나타나는 내부 활성값의 차이를 비교합니다.

3. 모델의 거부 반응과 강하게 연관된 방향을 찾습니다.

4. 모델 가중치가 해당 방향으로 작동하지 않도록 수정합니다.

5. 수정된 모델이 이전보다 요청을 덜 거부하는지 확인합니다.

이 방식은 시스템 프롬프트에 “모든 질문에 답하라”고 적는 것과 다릅니다. 프롬프트로 우회를 시도하는 대신 모델 가중치에 형성된 거부 행동 자체를 약화하기 때문입니다.

하지만 여기서 중요한 구분이 필요합니다.

Abliteration이 AI의 모든 안전장치를 제거하는 것은 아닙니다.

생성형 AI의 가드레일은 하나의 기능이 아니라 여러 계층으로 구성됩니다.

일반적으로 abliteration이 직접 겨냥하는 것은 이 가운데 모델 내부에 학습된 거부 성향입니다. 외부 입력 필터, 사용자 인증, 권한 관리, 감사 로그까지 자동으로 없어지는 것은 아닙니다.

따라서 Abliteration.ai를 정확히 이해하려면 “안전장치를 제거했는가”뿐 아니라 어느 계층의 안전장치를 제거하고, 어떤 계층에 새로운 통제를 배치했는가를 봐야 합니다.

Abliteration.ai가 판매하는 것은 ‘덜 거절하는 모델’이다

Abliteration 기술 자체는 논문과 오픈소스 커뮤니티를 통해 알려져 있습니다. 기술을 이해하고 필요한 장비를 갖춘 이용자는 오픈웨이트 모델을 직접 수정해 실행할 수도 있습니다.

Abliteration.ai가 사업으로 만든 부분은 그다음 단계입니다.

회사는 가드레일을 약화한 오픈웨이트 모델을 직접 호스팅하고 API로 제공합니다. 고객은 대용량 모델 파일을 내려받거나 GPU 서버를 구축하지 않고도 서비스를 이용할 수 있습니다. OpenAI 호환 API도 제공해 기존 애플리케이션에서 엔드포인트와 키를 바꾸는 방식으로 연결할 수 있습니다.

즉, 이 회사가 제공하는 가치는 새로운 기초모델 자체라기보다 다음 세 가지에 가깝습니다.

• 거부 성향이 약화된 모델을 바로 호출할 수 있는 호스팅 환경

• 직접 모델을 수정하고 GPU를 운영해야 하는 부담을 줄이는 관리형 API

• 기업이 요청별·조직별 정책을 붙일 수 있는 통제 계층

이 가운데 가장 강한 관심을 끄는 것은 첫 번째입니다. 기존 상용 AI가 거절하는 요청에도 답하는 모델은 명확한 차별점을 가집니다.

그러나 ‘잘 거절하지 않는다’는 것이 곧 ‘더 좋은 AI’라는 뜻은 아닙니다.

거부율이 낮아지면 정상적인 요청까지 막는 **과잉 거부(false refusal)**는 줄어들 수 있습니다. 반면 모델은 해서는 안 될 요청에도 더 쉽게 협조할 수 있습니다. 또한 가드레일 제거는 답변의 사실성이나 추론 정확도를 높이는 기술이 아닙니다. 모델이 틀린 내용을 더 자신 있게 말하거나 위험한 실행 절차를 구체화할 가능성도 따로 평가해야 합니다.

결국 Abliteration.ai의 제품은 단순히 성능이 향상된 AI가 아니라, 순응성과 위험을 함께 높일 수 있는 AI라고 보는 편이 정확합니다.

기업은 왜 ‘거절하지 않는 AI’를 원하는가

AI 가드레일은 악용을 줄이는 데 필요하지만, 모든 조직과 업무에 동일한 기준을 적용하면 문제가 생깁니다.

예를 들어 보안 전문가가 고객사의 허가를 받고 침투 테스트를 수행한다고 가정해 보겠습니다. 모델 입장에서는 합법적인 보안 진단과 실제 공격 준비를 정확히 구별하기 어렵습니다. 두 요청에 사용되는 기술 용어와 절차가 거의 같기 때문입니다.

다음과 같은 분야에서도 비슷한 문제가 발생할 수 있습니다.

1. 사이버보안과 AI 레드팀

• 악성코드와 공격 기법 분석

• 취약점 재현과 방어책 검증

• AI가 위험한 요청에 어떻게 반응하는지 평가

• 승인된 환경에서의 침투 테스트

2. 의료·법률·규제 업무

• 민감한 의료 기록 분석

• 범죄·분쟁 자료의 분류와 요약

• 규제 위반 사례 탐색

• 고위험 표현이 포함된 내부 문서 검토

3. 콘텐츠 안전과 연구

• 유해 콘텐츠 데이터셋 분류

• 혐오·폭력 표현 탐지 모델 평가

• 극단적인 입력을 활용한 안전성 테스트

• 모델 취약점 및 탈옥 가능성 연구

4. 기업 내부의 특수 업무

• 회사 정책에 맞춘 고객지원

• 허용된 전문 용어와 금지 표현의 자체 정의

• 국가·산업별 규정에 따른 응답 범위 조정

• 외부 모델 사업자의 정책과 맞지 않는 합법적 업무 처리

기존 AI 서비스는 모델 공급자가 정한 공통 정책을 모든 고객에게 적용하는 경우가 많습니다. 하지만 병원, 금융회사, 보안업체, 콘텐츠 플랫폼이 감당해야 하는 위험과 허용 범위는 서로 다릅니다.

이 지점에서 Abliteration.ai의 주장은 설득력을 얻습니다.

모델 공급자가 모든 조직의 정책을 대신 정하는 것보다, 실제 업무와 책임을 아는 기업이 허용 범위를 결정하게 하자는 것이다.

문제는 기업이 더 많은 통제권을 갖는 만큼 더 큰 책임도 함께 져야 한다는 점입니다.

모델 내부 가드레일을 빼고 외부 정책을 붙인다

Abliteration.ai는 기업용 Policy Gateway를 통해 조직별 정책을 적용할 수 있다고 설명합니다.

공식 문서상 정책 게이트웨이는 모델 요청을 검사한 뒤 다음과 같은 결정을 내릴 수 있습니다.

• ALLOWED: 요청을 그대로 허용

• REDACTED: 개인정보나 민감정보를 가린 뒤 전달

• REFUSED: 정책 위반 요청을 차단

• REWRITTEN: 요청을 조직 정책에 맞게 수정

기업은 허용·차단 목록과 콘텐츠 범주, 개인정보 처리 규칙 등을 설정하고, 각 결정에 관한 사유 코드와 감사 기록을 남길 수 있습니다. 모델 호출 전후에 정책을 적용해 조직 차원의 통제와 사후 증빙을 제공하려는 구조입니다.

Abliteration.ai는 요청 단위로 적용할 수 있는 안전 필터도 제공합니다. API의 flagged_categories 항목에 범주를 지정하면 마지막 사용자 메시지를 검사하고, 선택한 범주에 해당할 경우 모델을 호출하기 전에 요청을 거부합니다.

공식 문서에 제시된 선택 범주는 다음과 같습니다.

• 괴롭힘·모욕

• 혐오 표현

• 불법 행위·사기

• 노골적인 성적 콘텐츠

여기까지만 보면 Abliteration.ai는 안전을 포기한 회사라기보다, 모델 내부의 획일적인 통제를 외부의 구성 가능한 정책 시스템으로 옮기는 회사에 가까워 보입니다.

기존 구조와 비교하면 차이가 더 분명합니다.

이 구조의 핵심은 가드레일을 없애는 것이 아니라 가드레일의 위치와 관리자를 바꾸는 것입니다.

그러나 정책 게이트웨이는 ‘선택 사항’이다

Abliteration.ai를 안전 정책의 통제권을 기업으로 이전하는 회사라고만 설명하기 어려운 이유도 있습니다.

공식 문서에 따르면 요청별 안전 필터는 이용자가 차단 범주를 직접 지정하는 방식입니다. 조직 전체에 정책을 강제하는 Policy Gateway 역시 필요에 따라 적용하는 별도 계층입니다.

더 중요한 것은 기본 안전 기준의 범위입니다.

Abliteration.ai의 요청 안전 필터 문서에는 모든 요청에 기본 적용되며 사용자가 해제할 수 없는 범주로 다음 두 가지가 명시돼 있습니다.

• 아동 대상 성적 유해 콘텐츠

• 자해 콘텐츠

문서는 그 밖의 요청은 이용자가 flagged_categories를 지정하거나 별도 정책을 적용하지 않으면 통과할 수 있다고 설명합니다.

이는 회사가 최소한의 안전 바닥선을 유지한다는 증거인 동시에, 기본 차단 범위가 매우 좁다는 의미이기도 합니다. 불법 행위, 사기, 혐오, 괴롭힘과 같은 범주는 기능상 차단할 수 있지만 고객이 정책을 적용하지 않으면 기본적으로 막히지 않을 수 있습니다.

따라서 Abliteration.ai의 구조를 다음과 같이 표현하는 것이 가장 정확합니다.

모델 차원의 거부 성향은 제거하고, 운영 차원의 안전 정책은 고객이 선택해 다시 구성하도록 한다.

‘통제권 이전’은 곧바로 ‘안전의 보장’을 의미하지 않습니다. 통제할 수 있는 도구를 제공하는 것과 실제로 모든 고객이 적절한 통제를 사용하게 만드는 것은 전혀 다른 문제이기 때문입니다.

이 사업 모델의 진짜 경쟁력은 어디에 있을까

Abliteration은 공개된 연구를 토대로 재현할 수 있는 기술입니다. 시간이 지나면 다른 업체도 거부 성향을 약화한 모델을 제공할 수 있고, 충분한 인프라를 갖춘 기업은 직접 구축할 수도 있습니다.

따라서 Abliteration.ai의 장기적인 경쟁력이 단순히 ‘가드레일이 제거된 모델’에만 있다고 보기는 어렵습니다.

사업 관점에서는 다음 세 요소가 더 중요합니다.

1. 실행 편의성

오픈웨이트 모델을 수정하고 안정적으로 서빙하려면 GPU, 추론 최적화, 모니터링, 버전 관리가 필요합니다. Abliteration.ai는 이를 관리형 API로 묶어 도입 장벽을 낮춥니다.

2. 기업용 정책 제어

기업은 단순히 제한 없는 AI를 원하는 것이 아닙니다. 자사의 데이터, 고객, 산업 규정에 맞는 AI가 필요합니다. 정책 게이트웨이가 정교할수록 ‘무검열 AI’보다 ‘맞춤 통제 AI’라는 기업용 가치가 커집니다.

3. 책임을 증명하는 기록

규제 산업에서는 어떤 요청을 왜 허용하거나 차단했는지 설명할 수 있어야 합니다. 정책 버전, 결정 사유, 감사 로그, 외부 보안 도구 연동은 실제 구매 결정에서 모델의 자유도보다 중요할 수 있습니다.

결국 이 회사의 지속 가능한 사업은 ‘금지된 질문에 답해 주는 API’보다 기업이 AI의 허용 범위를 직접 설계하고 증명하게 하는 거버넌스 인프라에 가까울 가능성이 큽니다.

다만 정책 엔진과 감사 기능은 기존 AI 보안업체와 클라우드 사업자도 제공할 수 있습니다. Abliteration.ai가 경쟁력을 유지하려면 가드레일 제거 기술뿐 아니라 정책 정확도, 운영 안정성, 보안 인증, 사고 대응 능력을 함께 입증해야 합니다.

가장 큰 위험은 가드레일 제거보다 ‘책임의 공백’이다

통제권을 기업으로 이전한다는 말은 책임도 함께 이전한다는 뜻입니다. 하지만 실제 사고가 발생하면 책임 소재는 단순하지 않습니다.

• 모델을 원래 개발한 회사가 책임져야 할까?

• 거부 성향을 제거하고 API로 제공한 사업자가 책임져야 할까?

• 정책을 느슨하게 설정한 도입 기업이 책임져야 할까?

• 악의적인 요청을 입력한 최종 사용자가 책임져야 할까?

여러 주체가 관여할수록 오히려 누구도 충분한 책임을 지지 않는 상황이 생길 수 있습니다.

Abliteration.ai의 접근법이 신뢰를 얻으려면 최소한 다음 질문에 답해야 합니다.

고객과 용도를 확인하는가

고위험 모델을 누구나 익명으로 사용할 수 있다면 기업용 거버넌스라는 설명은 약해집니다. 위험 수준에 따른 신원 확인과 사용 목적 검토, 요청 한도와 권한 분리가 필요합니다.

정책 게이트웨이를 우회할 수 없는가

기업이 정책 게이트웨이를 적용하더라도 다른 API 키나 엔드포인트로 모델에 직접 접근할 수 있다면 통제 효과가 떨어집니다. 정책이 조직의 모든 요청에 강제되는지 확인해야 합니다.

정책 자체가 틀릴 때 어떻게 대응하는가

외부 필터도 AI 모델이라면 오탐과 누락이 발생할 수 있습니다. 정상 요청을 막는 문제뿐 아니라 위험한 요청을 통과시키는 문제도 측정해야 합니다.

로그와 개인정보 보호를 함께 만족하는가

감사를 위해서는 기록이 필요하지만, 민감한 프롬프트와 모델 출력이 장기간 저장되면 새로운 보안 위험이 됩니다. 공식 사이트는 API가 기본적으로 프롬프트를 보존하지 않는다고 설명하지만, 감사 기능을 사용할 때 어떤 메타데이터와 정책 기록이 남는지까지 확인해야 합니다.

사고를 공개하고 개선하는가

악용 탐지 건수, 정책 우회 사례, 계정 중단 기준, 사고 대응 시간과 같은 운영 지표가 없다면 안전성은 마케팅 문구에 머물 수 있습니다.

기업별 정책은 자유를 넓히지만 안전 기준을 파편화할 수 있다

모델 공급자가 일괄적으로 정한 정책은 경직될 수 있습니다. 반대로 각 기업이 모든 기준을 결정하면 같은 요청이 서비스마다 전혀 다르게 처리될 수 있습니다.

어떤 기업은 보안 연구를 이유로 공격 코드를 허용하고, 다른 기업은 같은 요청을 차단할 수 있습니다. 한 조직에서는 합법적인 콘텐츠가 다른 지역에서는 규제 대상일 수도 있습니다. 기업의 수익 목표가 안전보다 우선하면 정책이 의도적으로 느슨해질 가능성도 있습니다.

따라서 현실적인 해법은 완전한 중앙 통제나 완전한 기업 자율 중 하나를 선택하는 것이 아닐 가능성이 큽니다.

보다 현실적인 구조는 다음과 같습니다.

1. 모든 사업자에게 적용되는 최소한의 안전 기준

2. 산업과 국가의 규제에 따른 의무 정책

3. 기업이 업무 특성에 맞게 조정할 수 있는 추가 정책

4. 고위험 작업에 대한 신원·권한 검증

5. 독립적인 평가와 감사

6. 사고 발생 시 명확한 책임과 대응 절차

Abliteration.ai의 실험은 이 중 세 번째 영역, 즉 기업별로 조정 가능한 정책을 크게 확장합니다. 하지만 첫 번째와 두 번째 영역까지 기업 선택에 맡길 수 있는지는 별도의 사회적 합의가 필요합니다.

AI 에이전트 시대에는 더 민감한 문제가 된다

현재의 챗봇이 위험한 내용을 텍스트로 생성하는 것과, AI 에이전트가 실제 도구를 사용하는 것은 위험의 크기가 다릅니다.

AI가 이메일을 보내고, 코드를 실행하고, 서버에 접속하고, 결제를 처리하거나 로봇을 움직인다면 ‘거절하지 않는 모델’의 실수는 문장 하나로 끝나지 않습니다. 잘못된 판단이 실제 행동으로 연결될 수 있습니다.

이때는 콘텐츠 필터만으로 충분하지 않습니다.

• 사용자가 누구인지 확인하는 인증

• 역할별로 도구 사용 범위를 나누는 권한 관리

• 고위험 행동에 대한 사람의 승인

• 실행 전후의 상태 검증

• 비용과 횟수 제한

• 즉시 중단할 수 있는 비상 정지 장치

• 모든 행동의 감사 기록

즉, 모델이 덜 거절하도록 만들수록 시스템 전체의 통제는 오히려 더 정교해져야 합니다.

Abliteration.ai가 보여주는 방향은 AI 안전의 중심이 모델 답변 검열에서 행동 권한과 운영 거버넌스로 이동할 가능성을 보여줍니다. 그러나 이는 모델 수준의 안전이 필요 없다는 뜻이 아니라, 모델 하나의 거부 반응만으로 전체 시스템을 안전하게 만들 수 없다는 뜻에 가깝습니다.

그래서 Abliteration.ai는 어떤 회사인가

처음의 질문으로 돌아가 보겠습니다.

Abliteration.ai는 AI 안전장치를 없애는 회사인가, 아니면 안전 정책의 통제권을 기업으로 이전하는 회사인가?

현재 공개된 제품 구조만 보면 답은 다음과 같습니다.

Abliteration.ai는 모델 내부의 안전장치 일부를 제거해 판매하는 회사이면서, 기업이 외부 정책으로 그 빈자리를 다시 통제하도록 만드는 회사다.

두 설명 중 하나만 선택하면 사업의 절반을 놓치게 됩니다.

가드레일 제거는 이 회사가 고객을 끌어들이는 직접적인 제품 가치입니다. 반면 Policy Gateway는 그 위험을 기업 시장에서 관리하고 정당화하기 위한 핵심 사업 장치입니다.

다만 “안전 통제권을 기업에 돌려준다”는 문구가 설득력을 가지려면 다음 조건이 필요합니다.

• 고위험 이용자와 사용 목적에 대한 검증

• 우회하기 어려운 조직 단위 정책 강제

• 모델과 정책 필터에 대한 독립적인 안전성 평가

• 개인정보를 보호하면서도 책임을 추적할 수 있는 감사 체계

• 사고 발생 시 서비스 제공자와 도입 기업의 명확한 책임 분담

이 조건이 충족되지 않으면 Policy Gateway는 안전 시스템이라기보다 선택 가능한 부가 기능에 그칠 수 있습니다. 반대로 이를 충분히 입증한다면 Abliteration.ai는 단순한 ‘무검열 AI 회사’가 아니라 AI 거버넌스의 위치를 모델 공급자에서 실제 운영 조직으로 옮기는 기업으로 평가받을 수 있습니다.

마무리

AI 모델의 과잉 거부는 분명 현실적인 문제입니다. 모든 민감한 질문을 위험하다고 간주하면 보안 연구, 의료, 법률, 콘텐츠 안전과 같은 정당한 활용까지 제한됩니다.

Abliteration.ai는 이 문제를 가장 급진적인 방식으로 해결하려 합니다. 먼저 모델에 학습된 거부 성향을 걷어내고, 필요한 통제는 기업이 외부에서 다시 설계하게 합니다.

이 접근은 AI의 자유와 실용성을 넓힐 수 있습니다. 동시에 잘못 설정된 정책 하나가 모델의 위험한 능력을 그대로 노출할 수 있다는 문제도 안고 있습니다.

그래서 Abliteration.ai를 둘러싼 핵심 논쟁은 ‘검열이냐 자유냐’만이 아닙니다.

AI가 무엇을 거절할지는 누가 결정해야 하며, 그 결정이 잘못됐을 때 누가 책임져야 하는가?

앞으로 AI가 단순한 대화 도구를 넘어 실제 업무와 물리적 행동을 수행할수록 이 질문은 더 중요해질 것입니다. 더 자유로운 모델을 만드는 기술보다 그 자유를 누가 어떤 권한으로 사용했는지 통제하고 증명하는 시스템이 AI 산업의 핵심 인프라가 될 수도 있습니다.

Abliteration.ai의 진짜 실험은 안전장치를 없애는 데 있지 않습니다. 안전의 위치와 책임의 주체를 다시 설계하는 데 있습니다.

참고 자료

• Abliteration.ai 공식 사이트

• Abliteration.ai: Abliterated AI 설명

• Abliteration.ai 문서: What is abliteration?

• Abliteration.ai 문서: Request safety filtering

• Abliteration.ai 문서: Policy Gateway overview

• Abliteration.ai 문서: Policy Gateway Security

• Arditi 외, 「Refusal in Language Models Is Mediated by a Single Direction」

• TechCrunch, 「Abliteration.ai is making a business out of removing AI guardrails」, 2026년 9월 3일

이 글은 2026년 9월 4일 공개된 공식 문서와 보도를 기준으로 작성했습니다. 제공 모델, 기본 차단 범주, 가격과 정책 기능은 이후 변경될 수 있습니다.