A Base de conhecimento pública (Public KB) é a parte da sua base de conhecimento acessível sem autenticação por meio de um link direto, um widget ou um iframe. Chegam aqui os artigos que você marcou explicitamente como públicos.
Por quê:
- Autoatendimento do cliente — os clientes encontram respostas por conta própria, sem contatar o suporte
- SEO — os artigos públicos são indexados pelo Google e por outros mecanismos de busca
- Demonstração — clientes em potencial leem a documentação antes de comprar
- Parceiros — acesso à documentação técnica sem a necessidade de criar contas
#Como um artigo se torna público
A publicidade é ativada por duas configurações — uma no nível do artigo e outra no nível da organização. Até que ambas estejam em vigor, os visitantes anônimos não verão o artigo.
public e os artigos inherit dentro de uma pasta pública; internal e draft permanecem ocultos. Um artigo só pode ser marcado como público em um espaço Corporate — em espaços Private a publicação fica bloqueada.public.Não existe um TIPO de espaço "público". Os espaços são apenas Corporate / Private. Um artigo se torna visível não ao ser movido para um espaço especial, mas por meio da flag
publish_state=public(em um espaço Corporate) em conjunto com o modo de acesso público da organização ativado.
#Estados de publish_state (ADR 0029)
O LiKE usa o campo publish_state (ele substitui o antigo campo visibility). Quatro estados:
| Estado | Quem vê | Observação |
|---|---|---|
| draft | Apenas o autor e os editores do espaço | Um rascunho — não visível para a equipe e não incluído na busca |
| inherit | Segue a pasta pai mais próxima que tenha um estado explícito; se não houver nenhuma — como internal | ADR 0029 |
| internal | Todos os membros autorizados do espaço | Visível para a equipe (o valor padrão para novos artigos) |
| public | Todos, incluindo usuários anônimos por meio da Public KB | O distintivo de acesso junto ao título do artigo — apenas em um espaço Corporate |
Na interface, a cor do estado é mostrada por um indicador de ponto:
Os mesmos selos são visíveis na lista de artigos em Gestão de artigos.
#O espaço virtual __public__
Quando um usuário anônimo abre a Public KB por meio de um link direto ou de um widget, tecnicamente ele não está em nenhum dos seus espaços. Em vez disso, o LiKE usa um "espaço" virtual __public__ — um valor sentinela que:
- Não existe no banco de dados como um
ArticleCollection.type='public'real - Inclui os artigos públicos por si mesmos ou por herança de uma pasta pública
- É usado para filtragem na busca RAG do usuário anônimo
- É exibido no SpaceSwitcher como " Artigos públicos" (se o usuário também tiver espaços privados)
Se você for um membro autorizado, alterne para __public__ no SpaceSwitcher para ver exatamente o mesmo conjunto de artigos que um visitante anônimo vê — isso é útil para verificar "o que publiquei acidentalmente".
#Configuração (passo a passo)
#Passo 1 — Colocar os artigos em um espaço Corporate
Você só pode publicar externamente a partir de um espaço Corporate (em espaços Private a publicação fica bloqueada). Se os seus artigos estiverem em outro espaço, mova-os para um Corporate: um por um pelo menu de contexto do artigo → Mover, ou em massa (caixas de seleção → Mover). Os tipos de espaço são Corporate e Private; não existe um tipo "Personal" separado — um espaço permanece privado até que você convide alguém.
#Passo 2 — Tornar os artigos públicos
Mude os artigos que você precisa para publish_state = public (consulte Gestão de artigos):
- Em massa — selecione com as caixas de seleção → o botão de globo () na barra de ações → Public
- Um único artigo — o menu "⋮" → "Visibilidade: …" → Public; no modo "Árvore" — o menu de contexto → "Tornar público"
- No editor — o distintivo de acesso junto ao título do artigo
Depois disso, o indicador de status fica verde e um selo Public aparece. Se o artigo contiver dados pessoais, um diálogo de confirmação é aberto — consulte "Verificação de dados pessoais antes da publicação" abaixo.
#Passo 3 — Ativar o modo público da organização
Configurações → Organização → Modo de acesso → escolha "Público".
- Público — os usuários anônimos veem, no endereço público, os artigos marcados como públicos; os espaços privados permanecem disponíveis apenas por convite.
- Corporativo — tudo fica disponível apenas para membros autenticados; usuários externos sem autenticação não veem nada, mesmo artigos marcados como públicos.
Sem o modo "Público" ativado, o endereço público fica fechado — este passo é obrigatório.
O modo público funciona apenas nos planos em que está incluído. Se o acesso público não fizer parte do plano, o botão "Público" fica indisponível com a dica "O acesso público não está incluído no seu plano: visitantes anônimos não veem o portal.". Ao fazer downgrade do plano, o portal fecha-se sozinho para anônimos e, ao voltar a um plano adequado, reabre — o modo escolhido não é redefinido.
#Passo 4 — Endereço público e canais
Há três maneiras de abrir a base de conhecimento pública pronta:
- Portal público — a raiz do seu endereço
https://<seu-slug>.lynkora.pro: busca, respostas de IA e leitura de artigos sem autenticação. Um artigo individual fica em/kb/<article-slug>. - Widget JS — incorporado no seu site; o código do widget é obtido em Integrações → Canais (o card "Widget JS").
- iframe — incorporação da interface de busca completa em uma página.
Não há mais uma aba "Public KB" separada nas configurações (ADR 0029): a publicidade agora é definida pela flag do artigo + o modo da organização, em vez de uma lista de permissões de fontes. Os widgets são gerenciados em Integrações → Canais.
#Verificação de dados pessoais antes da publicação
Ao mudar um artigo para Público, o LiKE analisa-o automaticamente em busca de dados pessoais (PII). Se encontrar algum, a publicação é pausada e aparece um diálogo "Dados pessoais detetados" — antes de o artigo ficar acessível a todos sem autenticação.
Quando é acionada: quando o artigo passa a ficar acessível anonimamente — por mudança para public ou através de inherit dentro de uma pasta pública. Não é executada para internal nem draft. Funciona em todos os caminhos, e não apenas no botão "Publicar": o distintivo de acesso no editor, "Tornar pública" na lista e na árvore, a alteração de visibilidade em lote, a publicação de uma pasta (inclusive juntamente com o respetivo conteúdo), a mudança de um artigo ou de uma pasta para uma pasta pública, a cópia, a restauração a partir da lixeira e a ativação de um artigo.
O que é detetado (determinístico, baseado em padrões):
- Telefone
- Cartão de pagamento (checksum Luhn)
- IBAN (validado por checksum)
- Endereço IP
- Data de nascimento
Categorias especiais (saúde, biometria, etc., RGPD Art. 9) ainda não são detetadas automaticamente — o diálogo apenas mostra um aviso sobre a responsabilidade acrescida de as publicar.
Um grupo de artigos é perguntado uma única vez. A alteração de visibilidade em lote, a publicação de uma pasta, a mudança e a restauração mostram um único diálogo "Dados pessoais nos artigos a publicar": um resumo por tipo de dados (quantas ocorrências e em quantos artigos), a lista de artigos com pesquisa por título, "Marcar tudo" / "Desmarcar tudo" e o contador dos artigos marcados.
- Os artigos marcados são publicados. Ao abrir, estão todos marcados — desmarque aqueles que não devem ser publicados: ficam internos e não seguem a pasta.
- Os botões são "Publicar N" e "Cancelar". Ao cancelar nada acontece, e o LiKE di-lo de forma explícita.
- A confirmação dada no diálogo de grupo é escrita no registo para cada artigo separadamente.
Os artigos recolhidos pelo conector de site não exigem confirmação artigo a artigo: ao ligar o conector, a pessoa proprietária confirma os direitos sobre o site e a licitude da publicação dos dados pessoais provenientes dele. Ligue o site de novo com a resposta "Internas" — o consentimento é retirado e a verificação volta a funcionar como habitualmente.
As ações em segundo plano — a sincronização do conector, a importação, a reconstrução da estrutura — não podem perguntar a ninguém e, por isso, não publicam um artigo com dados pessoais não confirmados: ele permanece interno e fica uma entrada sobre isso no registo. É possível publicá-lo manualmente, passando pela verificação habitual.
O que o diálogo de um único artigo mostra:
- O título "Dados pessoais detetados" e uma lista dos tipos detetados com as respetivas contagens (agregadas em todos os artigos a publicar).
- Uma caixa de confirmação obrigatória: a ferramenta ajuda a detetar PII mas não garante a exaustividade; você, enquanto responsável pelo tratamento, continua responsável pela licitude da publicação e por dispor de uma base legal ou consentimento.
- Botões Cancelar e Publicar (Publicar só fica ativo depois de a caixa ser marcada).
Após a confirmação: o artigo é publicado e a confirmação é registada no registo de atividade (pii_public_ack) com os tipos de dados detetados — sem armazenar o próprio texto dos PII (privacy-by-design). A confirmação está associada à versão atual do artigo: se editar o texto posteriormente, terá de confirmar novamente.
Quem pode confirmar: as mesmas funções que podem publicar — Editor e superior no espaço do artigo. O Owner da organização — sempre; o Admin da organização — nos espaços corporativos e nos privados em que é membro com a função Editor ou Admin. Publicar todos os artigos de uma fonte em lote é apenas para Owner/Admin.
#Widgets para a Public KB (dual-auth, ADR 0032)
O LiKE suporta dois modos de autenticação para widgets — escolhidos ao criar um widget em Integrações → Canais → JS Widget:
#Modo 1 — Caminhos permitidos (para sites públicos)
Um widget incorporado no site público da empresa (uma landing page, páginas de marketing, uma central de ajuda). Nenhuma autenticação é necessária — o widget está disponível para qualquer visitante.
Proteção contra abuso:
- Endereços do site — onde o widget funciona. Por exemplo,
seusite.com, docs.seusite.com(um endereço sem esquema recebehttps://). O asterisco não é aceito; requisições de outros endereços são rejeitadas. - Escopo public umbrella — o widget tem acesso apenas ao espaço
__public__+ coleções específicas desse espaço, definidas na criação. - Rate limit na api-key — proteção contra bots.
#Modo 2 — Session JWT (para um site corporativo com autenticação)
Um widget incorporado no portal interno da empresa, onde os usuários já possuem autenticação. O widget aceita um session JWT e vê exatamente o que aquele usuário vê.
Casos de uso:
- Um widget em uma intranet corporativa → cada colaborador vê seus próprios espaços
- Incorporação em uma aplicação SaaS (por exemplo, em um CRM) — o usuário vê a documentação para sua função
#Multi-widget por tenant (ADR 0029 Stage 4)
Dentro de uma organização, você pode criar vários widgets com escopos diferentes:
- Um — público, para o site de marketing (allowed paths)
- Outro — corporativo, para a intranet (session JWT)
- Um terceiro — para uma coleção específica (por exemplo, apenas o FAQ para a central de suporte)
Cada widget tem sua própria api-key, escopo e modo de autenticação. Consulte Integrações e API e widget para mais detalhes.
#O que os visitantes anônimos veem
| Elemento | Visível? |
|---|---|
Artigos com publish_state=public e artigos inherit em pastas públicas |
Sim |
| Busca por IA nesses artigos | Sim (com o volume de IA da organização esgotado — busca de artigos por significado, sem resposta da IA) |
| O catálogo de coleções públicas | Sim |
| Um link curto de compartilhamento / incorporação (se ativado para o artigo) | Sim |
| O banner "Faça login para acesso completo" (se o widget for anônimo) | Sim |
Artigos internal, draft e inherit fora de pastas públicas |
Não |
| Artigos de espaços privados | Não |
| Histórico de consultas / Recomendações (pessoais) | Não |
| Painel de administração, Lixeira, Log, Análises | Não |
A busca anônima usa por padrão um cookie de client-fingerprint para um rate limiting básico, mas não vincula a requisição a uma conta de usuário.
#Ocultar coleções individuais
Em um espaço Corporate, nem todas as coleções precisam necessariamente ser visíveis para usuários anônimos. Você pode ocultar coleções específicas:
- O menu de contexto da coleção → "Tornar pública" / "Tornar interna"
- O estado da coleção:
- inherit — segue a pasta pai mais próxima que tenha um estado explícito; se não houver nenhuma — interna (padrão)
- internal — oculto de usuários anônimos, visível para a equipe
- public — explicitamente público (apenas em um espaço Corporate, caso contrário, bloqueado)
Isso proporciona flexibilidade: por exemplo, em um espaço Corporate "Documentação", você pode manter rascunhos em uma coleção Internal Drafts com publish_state=internal — eles são invisíveis para o exterior, mas disponíveis para seus editores.
#Incorporação em um site
A Public KB pode ser integrada a um site de três maneiras:
| Método | Descrição |
|---|---|
| Link direto | https://<slug>.lynkora.pro — um site de portal completo com uma lista de artigos, busca por IA e navegação |
| Widget JS | Um botão flutuante no canto de qualquer página; ele se expande em um chat de IA e busca; o comportamento é configurável e, nos planos com white-label, o branding também |
| iframe | Um bloco incorporado (por exemplo, uma página de "Ajuda" dentro da sua aplicação) — a interface completa do LiKE em um quadro |
| REST API | Requisições diretas do seu backend por meio de uma api-key — para integração em suas próprias interfaces |
Detalhes sobre cada um — API e widget e Integrações.
#White-label e um domínio personalizado
A base de conhecimento pública está disponível no endereço padrão slug.lynkora.pro. Recursos avançados do portal — white-label (sem o branding do LiKE) e a conexão de um domínio personalizado (Configurações → Domínio; em desenvolvimento) — estão incluídos nos planos onde o white-label está habilitado. Não há um complemento pago separado para isso.
Quais recursos estão disponíveis em quais planos e por qual preço — consulte a página de Preços e o seu painel de administração.