Review each component, transfer, storage location, and operating responsibility before deciding whether the deployment fits your controls.
Can our reviewers follow the complete meeting-content path?
Audio capture and transcription occur on the Windows device. The finalized transcript is sent to the configured processing server, which returns a generated summary.
The local recording file is written under the desktop application’s configured recordings location.
The local speech process produces live segments and a final transcript. Transcript and meeting metadata are stored in the desktop SQLite database.
The API receives transcript text, optional timed segments, and session identifiers where applicable.
The server-side language model processes the transcript. Job state is recorded in SQLite and the completed result is written to the server’s result storage.
The authenticated desktop polls the job and saves the completed summary to its local database.
The current transcript summary endpoint does not upload the meeting audio file. This is narrower than claiming that “all data stays on one device”: transcript text is intentionally sent to your processing server.
Which systems hold which types of data?
A review should assess all three. Customer-operated AI processing does not mean the Wislab Portal is absent from account authentication.
Primary control: endpoint security, account access, filesystem permissions, and device retention.
Not the summary engine: the Portal does not receive meeting audio or run the meeting-analysis job in the current architecture.
Primary control: host security, network exposure, transport protection, database access, logs, backups, and retention.
What security mechanisms exist in the current implementation?
These mechanisms do not replace secure deployment. They provide application-level controls that your infrastructure must support.
The desktop authenticates processing API requests with an access token issued through the Wislab Portal.
Longer-lived refresh credentials allow the desktop to renew access without repeatedly asking the user to sign in.
When enabled on the processing server, collaboration-session APIs and uploads validate that the authenticated user belongs to the session.
An optional server-side workflow can request responses from external calendar invitees and block a calendar-linked upload until consent status permits it.
Public consent-response tokens are stored as hashes on the processing server rather than retained in plaintext.
Users can delete a meeting record together with its local audio, transcript, summary, and associated local search entries.
These controls are not a certification and do not establish compliance by themselves. Legal, privacy, records, security, and recording-consent obligations remain specific to your organization and deployment.
What remains our responsibility if we deploy Wislab?
The processing server is not a managed Wislab inference service. Your organization must apply the controls expected for an internal system handling meeting transcripts.
Use HTTPS for production traffic and control how desktop endpoints reach the processing server. Development examples using HTTP are not a production security recommendation.
Protect Windows accounts, local recording folders, the desktop SQLite database, and device backups.
Patch the host, restrict network access, protect model and database files, manage secrets, and monitor server health.
Keep token signing configuration, issuer, and audience aligned between the Portal and processing server, and protect signing material.
Define deletion, server-job retention, desktop recording retention, backup scope, and restoration procedures.
Determine when recording is lawful, notify participants, configure optional consent features where useful, and maintain your own policy controls.
What will our security team ask first?
Audio is captured and transcribed on the user’s Windows device. The current summary request sends transcript text to the configured processing server and does not send the audio file.
The finalized transcript is stored in the desktop SQLite database. Transcript text is also processed and recorded as part of the summary job on the organization-operated processing server. Retention on both systems must be considered.
Wislab does not receive meeting audio or transcript text through the Wislab-operated Portal in the current architecture. Meeting content stays on your desktop endpoints and processing server. Access could still occur if your organization explicitly shares logs, files, or system access for support, so support procedures should be governed accordingly.
Yes. That is the current deployment model. Your organization supplies and operates the FastAPI processing server and configures each desktop with its reachable server URL.
The current Terms state that users retain ownership of recordings, transcripts, summaries, and other content they create or store through Wislab. Your organization should still review contractual terms for its intended deployment.
Wislab does not claim built-in encryption at rest for the desktop SQLite database, recording files, or default server database. Your team should apply operating-system, disk, database, and backup controls appropriate to the deployment.
The production deployment should expose the processing API over HTTPS. Local and lab configurations can use HTTP, so encryption depends on the URL and network architecture your organization deploys.
The site does not claim general enterprise RBAC. The current implementation authenticates users and can enforce collaboration-session membership on the processing server. Those controls are narrower than organization-wide roles and granular meeting permissions.
The Portal supports account sign-in, desktop token issuance and refresh, and website inquiries. It is a separate boundary from the organization-operated processing server used for meeting summaries.
No certification is claimed on this website. Architecture choices can support an organization’s control objectives, but deployment alone does not establish compliance.
The next step is a technical discussion covering your network, endpoint, identity, retention, and pilot requirements.