SWISS SECURITY & DATA POSTURE
Customer control, explained precisely.
Security starts with knowing which data a workflow can read, which actions it can take and who is responsible when something goes wrong.
The implementation principles below are delivery commitments to agree within a customer scope. They are not evidence of a security certification or a completed customer audit. The section 'What this website does today' describes the behaviour of aifab.ch itself.
Your accounts. The minimum access.
Production implementations are designed for customer-owned accounts and customer-controlled credentials. We agree which identities may read, draft, approve and execute; broad administrator access is not the default.
Integration permissions, provider terms and data-location requirements are checked during scoping. A platform name on this site does not guarantee compatibility with every tenant policy or subscription.
- Approved connection identity and a named customer owner
- Bounded source and destination permissions
- Server-side secrets, with no credentials in prompts or public client code
- Revocation and handover responsibilities documented
Approved sources, explicit data paths.
The workflow scope identifies what data is necessary, which systems receive it and which providers process it. Retention, logging and cross-border requirements are customer-specific decisions, not assumptions based on AIFAB's Swiss location.
Source permissions must continue to apply when information is retrieved and presented. Sensitive data, regulated decisions or sector-specific requirements need explicit review before implementation.
Assessing a Swiss-hosted deployment.
A Swiss location alone does not prove data residency. A proposed customer-controlled deployment needs evidence across the complete processing path before it can be offered as a validated option.
A Swiss-hosted open-weight reference path remains unvalidated. Assessment must cover:
- Verified Swiss hosting and account ownership
- Documented storage, logs, backups, telemetry and support access
- Network evidence showing no unapproved model-provider egress
- Equivalent approval, fallback and acceptance controls
- Legal and privacy review of the actual providers and responsibilities
Prepare for failure before release.
Acceptance covers invalid input, ambiguity, missing sources and unavailable integrations. Logging should make a failure diagnosable without needlessly copying sensitive payloads.
Before production, agree monitoring, escalation, recovery and version rollback. Retrying a request must not duplicate a consequential action. A rollback cannot automatically undo an email already sent or another irreversible external effect.
- Versioned configuration and instructions
- A tested recovery path and named incident owner
- Defined support coverage rather than an implied 24/7 promise
- Dependency updates and regression checks before release
The Red Button: a customer-held pause with a manual path.
AIFAB designs a customer-assigned control that holds new automated effects after the pause is acknowledged. Queued work keeps its state, and new cases follow the documented manual path until an authorised owner restores controlled operation.
The five local demonstrations expose this control and show that replay, scenario changes and workflow switching do not silently clear it. A customer implementation still needs system-specific acceptance evidence: a pause cannot recall an email or another external action that already completed.
- Pause authority assigned by the customer
- New automated effects held at the agreed control boundary
- Manual handling, ownership and queued state preserved
- Explicit authorised restoration
- Bounded control events without business payloads
What this website does today.
The five public demonstrations run locally with synthetic fixtures. There are no document uploads, live model calls, customer system connections or operational actions.
The application serves fonts locally. Theme preference uses local storage. The Fit Checker and ROI calculator run locally; optional structured result handoff and bounded referral information use tab-local session storage for up to 30 minutes. No free-text task descriptions or contact details are stored there.
Contact and result-email endpoints validate input and fail closed when delivery or shared rate protection is unavailable. Resend handles requested email delivery and an Upstash Redis resource applies shared abuse protection. The application does not keep an enquiry database. Optional website analytics services are not active at launch.
The site is served over HTTPS with HSTS, a Content Security Policy that blocks remote scripts, frames and eval, MIME-sniffing protection and a restrictive referrer policy. Inline scripts and styles remain permitted for static rendering.
Report a security concern.
Use the Security report option in the protected contact form with a concise description, the affected page or service and a safe way to contact you. Please do not include passwords, access tokens, customer data or exploit code in the first message.
AIFAB will acknowledge the report, agree a secure channel where necessary and coordinate validation and remediation. Do not test against customer systems or access data that is not yours.
FURTHER INFORMATION
FDPIC information-security guidance
Official guidance and provider information relevant to this notice.