Security Methodology
Security is defined before implementation begins — every time.
AI security isn't about tool selection. It's about deciding what data can be used, for what purpose, and within what boundaries — before anything gets built. We start there.
The First Step on Every Project
We classify all data into three tiers before building anything.
Before any workflow is built, all operational data is classified into three tiers. Every workflow Blueprint Labs builds operates only within approved boundaries.
Clear for Use
Data that can be safely processed through AI workflows under appropriate access controls.
- General SOPs and policy documents
- Anonymized operational summaries
- Public product and service information
- Structured operational metrics (aggregated)
- Employee training and reference materials
Controlled Environment Only
AI workflows permitted only under strict controls: on-premise or private cloud, role-based access, and mandatory human review.
- Supplier contracts and pricing agreements
- Internal financial summaries and cost data
- Personnel records and HR documents
- Customer identifying information
- Engineering drawings and specifications
Off-Limits — Not for AI Processing
Data we do not include in AI workflows as a matter of principle. If use is required, it demands explicit legal and security review beyond Blueprint Labs' standard scope.
- Regulated personal data (HIPAA, PII with legal exposure)
- Classified or export-controlled materials
- Active litigation or legal hold documents
- Non-public financial information subject to disclosure rules
- Data under client confidentiality agreements
Classification is documented in writing at the start of every project. It's reviewed with operations, IT, and legal stakeholders before any workflow is designed. If the scope can't be set within approved categories, we'll tell you directly — and we won't build it.
How We Build
Six principles applied to every workflow we build.
Minimum Data Principle
Every workflow uses only the minimum data required to perform the task. We don't grant unnecessary data access for performance gains.
No Model Training on Client Data
We only use enterprise AI platforms that explicitly prohibit training on client data. Consumer-grade or free AI tools are never used in production.
Human Review Required on All AI Outputs
Any AI output that leads to action — sending an email, filing a document, updating a record — requires human review and approval first. No autonomous execution without sign-off.
Role-Based Access Control
AI workflow access follows the same principles as your existing data access controls. If an employee can't access a document, the AI assistant can't access it either.
Phased Rollout
New workflows deploy to a small user group first. We monitor for unexpected behavior, data processing issues, and user errors before expanding. No organization-wide rollout without a pilot phase.
Audit Trail Logging
Every production workflow logs AI processing activity, reviewed outputs, and human approval decisions. Operations owners can verify what AI processed and how outputs were used at any time.
Deployment Architecture
It runs inside your AWS account.
The AI systems Blueprint Labs builds deploy into your existing AWS account. Documents, embeddings, queries, responses — all data stays within your VPC boundary. Nothing leaves your infrastructure.
Why AWS Bedrock
Bedrock delivers three properties simultaneously that clear enterprise security reviews:
- ① Runs within your IAM boundary — no cross-account access required
- ② Anthropic contractually does not use your prompts or responses for training, and does not retain them
- ③ CloudTrail, VPC flow logs, and PrivateLink support — automatically generates the evidence auditors require
Maps directly to Samsung SQMS audits, ISO 27001, and SOC 2 Type II control requirements.
Deployment Options
Three deployment options
Deployment method is selected based on workflow data sensitivity and compliance requirements. Most clients start with AWS Bedrock.
Prototype
Direct Claude API call. For concept validation and internal R&D. Not used with operational data.
- Fast idea validation
- LLM inference sent to Anthropic servers
- Non-sensitive internal data only
- Internal phase — not sold to clients
Private Cloud (AWS Bedrock)
Run Claude or Nova inside your AWS account. The default architecture that passes Samsung supplier security reviews.
- Stays in your AWS account — no training, no retention
- PO documents, SQMS compliance, spec sheets, supplier contracts
- Auditable via CloudTrail + VPC flow logs
- Deploys to existing AWS infrastructure — no new vendor contract
Air-Gapped Self-Hosted
Run Llama 3 or Gemma (open-source) on your EC2 instances. Operates entirely inside your VPC with zero internet connections.
- Zero external calls — fully air-gapped
- Export-controlled data, contractual API restrictions
- Supports Samsung direct audit requirements
- Gemma 4, Llama 3, and other open-source models
Start on Bedrock. Migrate to air-gapped when data requirements or audit demands justify it. Same codebase, different endpoint.
For the Most Sensitive Workflows
When data can't leave your environment
Most enterprise AI providers offer strong data protections. But some workflows — especially those involving proprietary supplier agreements, confidential operations data, or contractually restricted materials — may not allow sending prompts and documents to an external API.
In those cases, Blueprint Labs can design workflows around privately deployed open-source models running inside your controlled environment. Inference stays on your infrastructure. Documents and prompts never leave your network.
This approach requires appropriate infrastructure — typically a private cloud environment or on-premise GPU compute — and is evaluated during the prioritization stage when data classification indicates restricted or high-sensitivity scope.
Important: model choice is one layer
Deploying a model privately keeps inference local — but that alone doesn't make it secure. The entire system flow needs to stay internal: where inference runs, where embeddings are stored, what gets logged, whether external APIs are called, and how access is controlled. Blueprint Labs designs the controls around the model, not just the model deployment.
When this option makes sense
- ✓Data classified as Restricted in the boundary framework
- ✓Contractual obligations that restrict third-party data processing
- ✓Internal knowledge, document review, or briefing workflows that don't require frontier model performance
- ✓Buyers whose primary concern is third-party exposure or data sovereignty, not maximum model capability
What "private deployment" requires
- —Private cloud or on-premise compute capable of running the chosen model
- —Fully private inference stack with no external API calls in the workflow chain
- —Internal storage for embeddings, logs, and outputs
- —Access controls, telemetry review, and audit logging aligned with your broader security posture
"You can make AI useful for your operations without sending internal documents to a public AI service."
Tooling Standards
Enterprise-grade tools only.
We don't use consumer AI products in production. Every tool is evaluated against four criteria: data residency policy, enterprise data protection agreement, access control, and audit logging.
Claude for Enterprise
Anthropic's enterprise tier with no training on client data and SOC 2 compliance.
Azure OpenAI
Microsoft-hosted models with HIPAA eligibility, enterprise data protection, and US data residency.
Google Gemini Enterprise
Google Cloud enterprise tier with client data isolation and compliance commitments.
AWS Bedrock
Run Claude, Nova, or Llama inside your AWS account. No training on client data, CloudTrail audit support, PrivateLink-compatible. Deploys to existing AWS infrastructure — the default architecture for Samsung supplier security reviews.
Privately Deployed Open-Source Models
For restricted-category workflows, open-source models deployed on client-controlled infrastructure. Inference and data never leave your environment.
Microsoft 365 + Copilot
For organizations already in the Microsoft ecosystem with established compliance postures.
Read-Only Connectors
All database integrations use read-only connectors. No write permissions are granted to AI components.
SSO / Identity Integration
AI workflow access is managed through your existing identity provider, not standalone credentials.
Audit-Grade Logging
Every AI interaction is logged with query, output, reviewer ID, and decision outcome.
Tool selection is driven by your environment and requirements, not vendor preference. Recommendations are presented with written rationale during the design stage.
Hard Limits
What we won't do
Our principles include knowing what we won't build. Even when clients request it, we don't build workflows that fall outside our security methodology.
If a workflow can't be safely scoped, we'll say so directly and explain why. We don't engineer around security concerns to win a project.
Systems that send emails, update records, or execute actions without a responsible party reviewing and approving the output first.
Workflows that access or process data from out-of-scope categories — including consumer-facing or regulated data.
Free or consumer-grade AI products don't provide data processing guarantees. We don't use them in production operations.
If we can't track what AI processed and how the output was used, we don't build on it. Audit trails are a feature of operational AI, not a cost.
Questions about our methodology
Have specific security requirements to discuss?
The Workflow Audit includes a pre-implementation security scoping conversation. If you have specific data handling requirements, compliance obligations, or IT constraints, that's exactly where we start.