Inteligencia artificial: hype y realidad

Recientemente tuve el honor de participar como invitado en una mesa redonda, auspiciada por la Escuela de Verano de la Red Temática en Tecnologías del Habla (RTTH), en la cual el tema principal era aparentemente simple: las tecnologías del habla y su lugar en la industria. En ella participamos Arantza del Pozo, de Vicomtech, Carlos Turró, del ASIC/UPV, y un antiguo compañero de nuestra época académica: Jesús Andrés, de Nuance.

Foto de la cena de gala de la Escuela de Verano 2017 de la RTTH

Decía aparentemente simple porque, a priori, no tenía ni idea de cómo íbamos a rellenar una hora y media que los organizadores habían reservado para la discusión. Sin embargo, conforme empezó el debate nos dimos rápidamente cuenta de que existe (y podríamos decir que ha existido siempre) un abismo entre aquello que la sociedad percibe como inteligencia artificial y lo que finalmente toma forma como un producto comercializable. Bien es cierto que ha habido avances muy notorios en los últimos años: la tecnología de reconocimiento del habla que utilizan los móviles modernos está ya mejorando las tasas de error que alcanzan los humanos, los coches automáticos son ya una realidad, y los chatbots están teniendo ahora mismo un auge muy importante. Sin embargo, todo esto contribuye a que la sociedad perciba que “todo es posible” con la tecnología (a lo cual ya le dedicó Zuzanna un post hace un tiempo).

Curva de madurez de las tecnologías. Fuente: wikimedia.org

Pero lo cierto es que es muy frecuente que una empresa termine llevándose una gran decepción cuando decide implementar soluciones de aprendizaje automático o inteligencia artificial. Sin embargo, esto no es necesariamente porque la tecnología no está lo bastante madura, sino porque la tecnología es mucho más compleja de lo que se espera: lejos de ser una tecnología que se puede utilizar out of the box, con frecuencia es necesario adaptarla a las necesidades del usuario y al problema concreto que se quiere abordar. Sin esto, nos encontramos con que las soluciones de aprendizaje automático que se adoptan no llegan a proporcionar los beneficios prometidos, generando frustración y decepción entre quien se decide a poner en marcha un proyecto de estas características.

Además, existe otro requisito básico imprescindible para poner en marcha muchas soluciones de aprendizaje automático: tener bien definidos y digitalizados los procesos de negocio. Aunque esto no es un requisito en algunos casos, lo más probable es que, si las soluciones de aprendizaje automático que se implementen no están bien integradas dentro de los procesos de negocio habituales de la organización, el proyecto termine en un bonito conjunto de software, al cual nadie le da ningún uso.

Evidentemente, estos son sólo dos de los problemas más habituales que llevan al fracaso de proyectos de implementación de tecnologías de aprendizaje automático. Sin embargo, la necesidad de integración fue seguramente el punto más importante en el cual coincidimos todos los que participamos en la mesa redonda. Nada nuevo, en realidad, porque ya en el 2002 afirmó Gartner Group que entre el 65% y el 80% de los proyectos de implantación de CRM fracasan precisamente debido a la incompatibilidad con los procesos de las empresas.

Por ello, en Sciling nos hemos especializado en adaptar soluciones de aprendizaje automático a las necesidades concretas de cada organización, desarrollando soluciones personalizadas. Además, y conscientes también de la necesidad de integrar dichas soluciones dentro del flujo habitual de trabajo de la organización, contamos con experiencia en modelado de procesos BPMN y en desarrollo de APIs REST. Así, minimizamos los riesgos derivados de la implantación de una herramienta de aprendizaje automático.

¿Qué es el phishing?

El Phishing o suplantación de identidad es un término informático que describe un modelo de abuso informático y que se comete mediante el uso de ingeniería social. A través de este método se intenta adquirir información confidencial de forma fraudulenta, como por ejemplo contraseñas o información detallada sobre tarjetas de crédito. El estafador, conocido como phisher, se hace pasar por una persona o empresa de confianza en una aparente comunicación oficial electrónica.

Fuente: wikimedia.org

¿Qué tipo de información roba?

El tipo de información que desea obtener el ciberatacante suelen ser contraseñas, información bancaria, ya sea el número de cuenta corriente y contraseña o bien toda la información relativa a una tarjeta de crédito. Este método también puede ser usado como ataque para recolectar datos iniciales sobre la empresa, institución o persona a la cual se desea atacar para obtener información de contexto que se usará para próximos ataques mediante el uso de ingeniería social. Como ejemplo, podríamos describir un supuesto donde el atacante requiere penetrar en el sistema de una empresa. El ciberatacante podría crear una página web idéntica a cualquier red social o servicio de correo electrónico dónde obtendría, por ejemplo, el correo electrónico, contraseña y teléfono. En un principio, estos datos podrían no ser significativos para la penetración en el sistema interno de la empresa, pero podría darse el caso donde ese empleado utilice ese mismo correo y esa misma contraseña para iniciar sesión en la intranet de la empresa, con lo que el atacante ya tendría unas credenciales para utilizarlas en una primera incursión en el sistema.

¿Cómo puedo reconocer un mensaje de phishing?

Si hablamos de reconocer un correo electrónico que emula una comunicación oficial de una entidad cualquiera, debemos poner hincapié en los siguientes campos:

  • El campo De: del mensaje muestra una dirección de la compañía. Desgraciadamente es sencillo para el estafador modificar la dirección de origen.
  • El mensaje de correo electrónico presenta logotipos o imágenes que han sido recogidas del sitio web real al que el mensaje fraudulento hace referencia.
  • El enlace que se muestra parece apuntar al sitio web original de la compañía, pero en realidad apunta a una página web fraudulenta.
  • Normalmente estos mensajes de correo electrónico presentan errores gramaticales que no son usuales en las comunicaciones de la entidad por la que se están intentando hacer pasar.

Si hablamos de una página web fraudulenta, debemos fijarnos en los siguientes aspectos:

  • Verificar que el certificado de seguridad coincida con la URL a la que se está accediendo
  • Verificar que se está usando el protocolo HTTPS
  • Cuando haya enlaces, verificar el destino de éstos mediante el posicionado del cursor del ratón sobre éste.
  • Si pide datos fuera de lo normal, posiblemente sea phishing.

Consejos para protegerse del phishing:

  • Nunca entregues tus datos por correo electrónico. Las empresas jamás te solicitará tus datos financieros por correo o teléfono.
  • Si dudas de la veracidad, jamás hagas clic en un link incluido en el mismo.
  • Si aún deseas visitarla, no hagas clic en el enlace. Escribe la dirección en la barra de su navegador.
  • Si recibes un email de este tipo, elimínalo y jamás lo respondas.
  • Comprueba que la página web tiene una dirección segura que empieza con https:// y un pequeño candado cerrado que aparece en la barra de estado de nuestro navegador.
  • Cerciórate de escribir correctamente la dirección del sitio web que deseas visitar ya que existen cientos de intentos de engaños de las páginas más populares con solo una o dos letras de diferencia.

Todos los usuarios de Internet corremos el riesgo de ser víctimas de estos intentos de ataques. Cualquier dirección pública en Internet es susceptible de ser víctima de un ataque debido a los spiders o arañas que rastrean la red en busca de direcciones válidas de correo electrónico. Es realmente barato el realizar un ataque de este tipo y los beneficios obtenidos son cuantiosos con tan sólo un pequeñísimo porcentaje de éxito. La mejor manera de protegerse del phishing es entender la manera de actuar de los proveedores de servicios financieros y otras entidades susceptibles de recibir este tipo de ataques. Y sobre todo, nuestro mejor aliado será el sentido común. Si a una persona conocida no le proporcionas cierta información, ¿por qué ibas a dársela a un desconocido?

¿Cómo sabemos que un proyecto de desarrollo ha terminado?

Uno de los problemas recurrentes cuando se ejecuta un proyecto de desarrollo de software es saber cuándo el proyecto ha acabado, es decir, cuándo el cliente acepta la entrega del proyecto y se liberan los recursos para otros proyectos. Desde la perspectiva del cliente, el problema está en saber si la aplicación que se entrega hace lo que él espera que haga. Por otra parte, los desarrolladores suelen decir que una tarea está terminada cuando han terminado de escribir el código. Sin embargo, la programación inicial no siempre cubre las necesidades del cliente. Puede que la toma de requerimientos no haya sido precisa o puede que el código no funcione como el programador espera. En cualquiera de los dos casos, esto supone un inconveniente tanto para el cliente como para el desarrollador.

Criterios de aceptación

Por lo tanto, es importantísimo definir unos criterios de aceptación, es decir, una serie de reglas o hitos acordados previamente para que ambos coincidan en cuándo el proyecto ha terminado definitivamente. De hecho, las metodologías más aceptadas lo contemplan explícitamente. Por ejemplo, en PRINCE2 la temática de calidad ayuda a transmitir las expectativas de calidad de la descripción del producto del proyecto a cada uno de los productos del proyecto. A nivel más táctico, en SCRUM el equipo tiene que acordar una definición de hecho (definition of done). Sin embargo, ninguno de los dos concreta qué criterios de aceptación se han de seguir, ya que estos han de ser adaptados a cada tipo de proyecto.

En Sciling usamos las pruebas funcionales tanto para validar las aplicaciones web como las APIs que desarrollamos para terceros:

Pruebas para aplicaciones web

Selenium es una de las herramientas más populares para automatizar pruebas sobre aplicaciones web. Tiene la ventaja de poder configurar las pruebas con un editor muy sencillo y permite generar capturas de pantalla y vídeos que solemos presentar en los informes para la aceptación de los productos, como prueba de que la aplicación funciona según lo esperado. Estas pruebas son repetibles, de forma que el cliente puede ver en vivo cómo funciona el test. Además, antes de cada actualización se repiten las pruebas para asegurarnos de que la aplicación continúa funcionando.

Pruebas para APIs REST

Para las APIs REST definimos un fichero por cada caso que se quiera verificar, con la secuencia de llamadas al API con sus respectivos resultados. De esta forma, el cliente que tenga que integrar el API podrá comprobar que los resultados son los que se esperan. Además, es muy útil como ejemplo de uso del API. Si en cualquier momento se detecta un resultado incorrecto, se añade un caso nuevo con los resultados válidos, de forma que cuando se corrija el error no sólo se pase ese caso, si no todos los que se hayan definido con anterioridad. Entregamos un informe de cobertura de las pruebas como resultado. Además, el cliente puede repetirlos en el momento de la entrega si así lo desea.

{  
  "calls":[  
    {  
      "request":{  
        "method":"GET",
        "endpoint":"/api/config/MAX_NUM_ROWS"
      },
      "response":{  
        "statusCode":200,
        "body":{  
          "error":null,
          "data":{  
            "id":"**ignore**",
            "name":"MAX_NUM_ROWS",
            "value":"5",
            "createdAt":"**ignore**",
            "updatedAt":"**ignore**"
          }
        }
      }
    },
    {  
      "request":{  
        "method":"POST",
        "endpoint":"/api/config/MAX_NUM_ROWS",
        "body":10
      },
      "response":{  
        "statusCode":200,
        "body":{  
          "error":null,
          "data":{  
            "id":"**ignore**",
            "name":"MAX_NUM_ROWS",
            "value":"10",
            "createdAt":"**ignore**",
            "updatedAt":"**ignore**"
          }
        }
      }
    }
  ]
}
Ejemplo de test de un API RESTful.

Evidentemente, es muy complicado que las pruebas funcionales cubran todas las posibilidades de la aplicación. Así que nuestra recomendación es centrarse en los flujos de trabajo principales de la aplicación y en los casos críticos para el negocio, asegurando que las pruebas funcionales cubren especialmente bien estos casos. De esta forma es más fácil que se cumplan los beneficios esperados del proyecto.

¡Mantén tu sistema actualizado!

Lo ocurrido durante los últimos meses hace pensar que este año ha sido el año negro de la seguridad informática. En mayo nos enterábamos de que el ransomware WannaCry infectaba miles de ordenadores a nivel mundial, obligando a dejar fuera de servicio durante horas a muchas de las empresas afectadas. La última noticia viene de un nuevo ransomware con nombre Petya que ha conseguido tener un impacto similar llegando incluso a paralizar la actividad de los principales bancos y empresas de Ucrania, que es donde se ha reportado el primer caso de este virus informático.

Continuar leyendo “¡Mantén tu sistema actualizado!”

SQL vs NoSQL

Históricamente, las bases de datos se han venido representando como una agrupación de tablas y relaciones entre éstas. Para hacer consultas a estas bases de datos se emplea el lenguaje SQL. De ahí que a este tipo de bases de datos (relacionales) se las denomine informalmente “bases de datos SQL”. Sin embargo, existe otro tipo de bases de datos en las que los datos que se almacenan no tienen por qué guardar relaciones entre sí. A este tipo de bases de datos se las denominó NoSQL, en oposición honor a las populares bases de datos SQL.

Continuar leyendo “SQL vs NoSQL”

Pero… ¿lo habéis patentado?

Normalmente los desarrolladores de software no tienen que preocuparse sobre la protección de sus creaciones, ya sea porque trabajan en una empresa donde ya hay gente cualificada para ello o porque programan con mentalidad de código abierto compartiéndolo en GitHub y no les importa que otras personas lo usen. Pero puede darse el caso en el que llegue el momento de que queramos proteger algún programa para después darle uso comercial. En este post os explicaré brevemente qué dicen las leyes sobre la protección del software y qué pasos hay que seguir para que nadie se aproveche de nuestros bienes inmateriales.

Continuar leyendo “Pero… ¿lo habéis patentado?”

Buenas prácticas en minería de datos

En realidad, lo primero necesario es definir bien los términos. Para el propósito de este post, y puesto que ni la Wikipedia parece resolver bien la duda, voy a definir buenas prácticas como un conjunto de normas y acciones establecidas en base al análisis de un gran número de casos de éxito y de fracaso, y que surgen como factor común a los casos de éxito, estando con frecuencia ausentes en los casos de fracaso.

Continuar leyendo “Buenas prácticas en minería de datos”

Reconocimiento de emociones mediante IA

A día de hoy, los robots simplemente actúan y reaccionan en base a las percepciones que obtienen del medio. Actualmente, podemos interactuar con ellos mediante el habla, gestos y periféricos, como el teclado o el ratón. Pero, ¿es posible que un robot detecte con precisión la emoción de las personas?. Esta sería una interacción que, para las personas, nos es intrínseca e intuitiva pero en el mundo de la robótica no es el caso. Gracias a los algoritmos de detección de los puntos característicos de la cara (Cootes y Taylor, 2004) podemos entrenar modelos (Sohail y Bhattacharya, 2006) estadísticos que, basados en la distancia entre estos puntos, clasifiquen el estado emocional de la persona a partir de una imagen facial.

Continuar leyendo “Reconocimiento de emociones mediante IA”